Information Technology Reference
In-Depth Information
management, loading of shared memory segments, and other useful functions.
Most of these features were exclusively used by CMS, the only IBM OS designed
to run under the hypervisor.
Over time, this design pattern influenced other virtual machine systems. For
example, similar cooperation between guest OS and virtual machine monitor is a
hallmark of the Xen hypervisor, in which a guest can use hypercalls to efficiently
request services such as I/O and memory management. Other hypervisors also
now use hypercalls. A variant method is provided with VMware, which supplies
device drivers for virtual network devices for some guest operating systems, which
can be emulated more efficiently than the highly specific aspects of different physi-
cal network cards.
Nested CPU Resource Manager Problem
One largely unsolved problem is that of the nested CPU resource manager.
VM/370 provided a “fair share scheduler” that permitted delivery of preferential
CPU service to important guests, later refined into a share-based scheduler simi-
lar to ticket, share, or proportional weight schedulers like the Solaris Fair Share
Scheduler (FSS) and VMware scheduler. In these schedulers, users or virtual
machines are given access to CPU time based on relative proportions or weights
assigned to them.
This approach works well when a guest has only one purpose and one level of
importance, but it can be problematic when a virtual machine is itself a multi-
programming environment with work of different priorities, or when the guest
OS does background tasks that are not performance critical. Consider a modern
virtual machine in a VDI implementation: It should be given good response time
for mouse and keyboard events and interactive applications, but may also have
low-priority housekeeping work such as running a virus scanner or indexing a file
system. In the original mainframe context, this problem occurred with guests that
required good service for consoles, network devices, and interactive users, yet also
had low-priority number-crunching workloads.
Two types of problems can result from this situation in a resource-constrained
environment. First, if the guest is given a share value high enough to provide pref-
erential CPU access for both critical and unimportant work, it will have better-
than-needed CPU access and may run its unimportant work with better service
than other guests. Second, if the preferred guest's CPU share is large enough for
its important work but not for all of its tasks, a low-priority process may poten-
tially absorb the preferred CPU shares, causing the high-performance work to be
starved when it runs later. Both cases can produce CPU starvation at unpredict-
able times, causing inconsistent response times. The root cause is that the hyper-
visor does not generally recognize the relative importance of the work the virtual
Search WWH ::
Custom Search