[Info-vax] IBM nearing deal to acquire Red Hat

[Kerry Main]

> -----Original Message-----
> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: April 29, 2019 9:56 PM
> To: info-vax at rbnsn.com
> Cc: Arne Vajhøj <arne at vajhoej.dk>
> Subject: Re: [Info-vax] IBM nearing deal to acquire Red Hat
> 
> On 4/29/2019 8:17 PM, Kerry Main wrote:
> >> -----Original Message-----
> >> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Stephen
> >> Hoffman via Info-vax
> >> Sent: April 29, 2019 12:53 PM
> >> How to shed load too, for those cases when priority processing needs
> >> more capacity than is available in the pool.
> >>
> >> And this capacity-acquisition and load-balancing and load-shedding is
> >> all part of higher-end distributed process scheduling and as is being
> >> discussed else- thread, too.
> >
> > See Galaxy note above.
> >
> > While no longer supported on new HW, and currently not in the plans,
> > it certainly would be nice to see some future version of OpenVMS
> > resurrect these Galaxy features - perhaps using some of the new X86-64
> > built in virtualization features. But, yes, its not on the radar right
now.
> 
> What did Galaxy provide that standard x86-64 hypervisors do not?
> 
> Arne
> 

- dynamic (business rules e.g. time of day) or manual drag-n-drop of sharing
CPU pools between different and separate OS instances. OS1 could request and
be granted additional cpu's from a common pool for a few hours and then
automatically return the CPU's if its workloads dropped or if business rule
kicked in e.g. time of day. 
- shared memory between different OS instances

Example1 - 
- OS1 is interactive system that needs 12 cpu's to handle load during the
day, but only 6 to handle load after hours.
- OS2 is a batch system that needs only 6 CPU's to handle loads during the
day, but 12 cpu's for after hours processing
- at 17:00 a business rule kicks in and 6 CPU's are transferred from OS1 to
OS2
- at 06:00 the next day, another rule kicks in and transfers 6 cpu's back
from OS2 to OS1

Example2 -
- OS1 is interactive system that needs 12 cpu's during the day normally. At
the end of the month, the load increases quite a bit and the average cpu
utilization increases to 85%. A pre-defined rule kicks in and an additional
3 cpu's are transferred from the common CPU pool to OS1. Average cpu
utilization drops to 55%. When average cpu utilization drops below 40% for X
minutes, the 3 cpus from OS1 are transferred back to the common pool.

In both cases above, the native OpenVMS class scheduler (available on all
OpenVMS systems btw) ensures that one process does not "run away" and cause
unnecessary cpu utilization.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com