5.3. DLPAR-safe and DLPAR-aware applications

The dynamic logical partitioning function on AIX 5L Version 5.2 is designed and implemented to not impact the existing applications. In fact, most applications are not affected by any DLPAR operations results. Therefore, those applications are called DLPAR-safe applications.

There are two types of application classifications regarding DLPAR operations:

DLPAR-safe	Applications that do not fail as a result of DLPAR operations. The application’s performance may suffer when resources are removed, or it may not scale as resources are added.
DLPAR-aware	Applications that incorporate DLPAR operations that allow the application to adjust its use of the system resources equal to the actual capacity of the system. DLPAR-aware applications are always DLPAR-safe.

5.3.1. DLPAR-safe

Although, most applications are DLPAR-safe without requiring any modification, there are certain instances where programs may not be inherently DLPAR-safe.

There are two cases where DLPAR operations may introduce undesirable effects into the application:

• Programs that are optimized for uni-processor may have problems when a processor is added to the system resources.

• On programs that are indexed by CPU numbers, the increased processor number may cause the code to go down an unexpected code path during its run-time checks.

In addition, applications that use uni-processor serialization techniques may experience unexpected problems. In order to resolve these concerns, system administrators and application developers need to be aware of how their applications get the number of processors.

5.3.2. DLPAR-aware

DLPAR-aware applications adapt to system resource changes caused by DLPAR operations. When these operations occur, the application will recognize the resource change and accommodate accordingly.

Two techniques can be used to make applications DLPAR-aware:

• The first method is to consistently poll for system resource changes. Polling is not the recommended way to accommodate for DLPAR operations, but it is valid for systems that do not need to be tightly integrated with DLPAR. Because the resource changes may not be immediately discovered, an application that uses polling may have limited performance. Polling is not suitable for applications that deploy processor bindings, because they represent hard dependencies.

• Applications have other methods to react to the resource change caused by DLPAR operations. See 5.4, “Integrating a DLPAR operation into the application” on page 217.

Several applications should be made DLPAR-aware, because they need to scale with the system resources. These types of applications can increase their performance by becoming DLPAR-aware. Table 5-1 on page 216 lists some examples of applications that should be made DLPAR-aware.

Table 5-1. Applications that should be DLPAR-aware

Application type	Reason
Database applications	The application needs to scale with the system. For example, the number of threads may need to scale with the number of available processors, or the number of large pinned buffers may need to scale with the available system memory.
License Managers	Licenses are distributed based on the number of available processors or the memory capacity.
Workload Managers	Jobs are scheduled based on system resources, such as available processors and memory.
Tools	Certain tools may report processor and memory statistics or rely on available resources.

Applications should also be made DLPAR-aware, if they cause DLPAR requests to fail.

The following application specific conditions can cause DLPAR remove requests to fail:

• Processor bindings

• Large amounts of pinned memory

Processor bindings and attachments are obstacles to CPU removal, since they represent work units that cannot be rescheduled on other processors. DLPAR-aware programs remove these obstacles by unbinding, re-binding, or terminating before the operating system attempts to remove the resource. AIX provides several interfaces for binding and attaching to processors including bindprocessor(), ra_exec(), ra_fork(), and ra_attachrset(). If the bindprocessor() interface is used, then the target processor is always the Nth online processor. The other interfaces target logical processors, so there is a direct correlation between the processor being removed and the attachment, which is not necessarily the case with bindprocessor(). It should be noted that bindprocessor() bindings may also be resolved through application handlers that may have already been provided for dynamic processor deallocation (for example, CPU Guard).

Applications that pin large amounts of memory may cause DLPAR memory removal failures, since they impede the system’s capability to pin new memory pages, which is a critical component of the DLPAR support for memory. AIX has the capability to migrate pinned memory, but it must ensure that the target of the migration is also pinned, so it must be able to pin memory on demand to satisfy DLPAR memory remove requests. DLPAR-aware applications that pin lots of memory should resize their buffers so that portions of them can be unpinned, before the operating system attempts to remove memory. Applications pin memory through the plock() and shmget(SHM_PIN) interfaces.

Applications that have processor attachments and pin memory are DLPAR-safe and they should be made DLPAR-aware.

Applications are not impacted by the dynamic reconfiguration of I/O resources, because access to the device is controlled through the device support layer, which is not manipulated by DLPAR. The system administrator is expected to unload device drivers before initiating DLPAR remove requests and, in a similar vein, he is expected to manually configure them after performing DLPAR add requests to make them available to applications. The DLPAR support for I/O resources is therefore DLPAR-safe. For example, DLPAR I/O remove requests will fail If a device driver that is associated with the I/O resource is loaded. The device driver does not have to be open for the DLPAR remove operation to fail. It simply has to be loaded.