HP Virtual Server Environment: Tips for Application Developers

from the host. All mass storage is visible to guests as SCSI disks, regardless of the physical
connection. Applications that depend on devices not yet virtualized by Integrity VM will not run in a
virtual machine. The devices not yet virtualized include: tape drives, Fibre Channel HBAs, storage
array controllers and USB. (Few applications depend on specific device dependencies.) Note that
these limitations apply only to Integrity VMs. Applications running in nPars, vPars, psets and FSS
groups all have access to the physical I/O hardware the OS is running on, hence do not have these
limitations.
Topology Aware Applications
Some applications discover and use information about CPU and memory topology to optimize
performance. Among these applications, the most common optimization is to ensure that particular
processes and threads share a particular core, to ensure that particular processes and threads reside
in Cell Local Memory on a cellular machine, and that the core and the memory are in the same
Locality Domain (LDOM). Key APIs to discover this information and manage the application include:
 mpctl(2)
 mpsched(1)
 pstat(2) (pstat_getlocality, pstat_getdynamic, pstat_getgetprocessor, etc)
 pthreads
o (pthread_attr_{getprocessor, setprocessor}_np
o pthread_num_processor_np()
o pthread_processor_bind_np()
o pthread_processor_id_np()
o pthread_launch_policy_np())
 mmap(2)
More generally, any application that tries to identify and use a specific processor, or take advantage
of memory locality should be prepared to handle the case where those resources are removed during
execution. The documentation for these APIs discuss ways that the topology can change in a running
OS, as CPU and memory resources migrate in and out of the OS. The documentation also explains
what the system behavior is when these resources go away. In general the application will continue
to run, but the performance gains associated with the topology management will be lost.
Application developers may choose to provide policies to the system administrator to optimize
performance. These policies may include configuring systems with specific CPU and memory
resources dedicated to the application. These resources would not participate in resource migration
or sharing with other applications. See for example vparcreate –a core:path to assign a specific core
to a vPar. This core will remain associated with this vPar and will not be removed or migrated to
another vPar.
Optimizing Applications for VSE
An application can be designed to recognize and dynamically adapt to changes in the system
configuration. Not only is the application then resilient to changes in processor and memory
resources, but it can also respond to these changes to achieve the best performance given the
resources available. The application could use a monitoring system that regularly polls to discover
changes in the system configuration. Applications designed to scale with the system configuration,
including those that detect the number of available processors or the size of physical memory when
the application starts, can better take advantage of VSE features. Applications designed to respond
to changes in resource availability can deliver the best possible performance at peak loads with
maximum resources as well as at low loads with minimal resources.
Note that many applications naturally scale with workload, without any awareness of the actual
hardware topology. Single threaded applications, applications that launch a new thread for each
task, and applications with significantly more execution threads than cores will be managed by the