[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]

Technical Reference: Kernel and Subsystems, Volume 1

dr_reconfig System Call

Purpose

Determines the nature of the DLPAR request.

Syntax

#include <sys/dr.h>

int dr_reconfig (flags, dr_info)
int flags;
dr_info_t *dr_info;

Description

The dr_reconfig system call is used by DLPAR-aware applications to adjust their use of resources in relation to a DLPAR request. Applications are notified through the use of the SIGRECONFIG signal, which is generated three times for each DLPAR event.

The first time to check with the application as to whether the DLPAR event should be continued. An application may indicate that the operation should be aborted, if it is not DLPAR-safe and its operation is considered vital to the system. The DR_EVENT_FAIL flag is provided for this purpose.

The application is notified the second time before the resource is added or removed, and the third time afterwards. Application should attempt to control their scheduling priority and policy in order to guarantee timely delivery of signals. The system does not guarantee every signal that is sent is delivered before advancing to the next step in the algorithm.

The dr_reconfig interface is signal handler safe and may be used by multi-threaded programs.

The dr_info structure is declared within the address space of the application. The kernel fills out data in this structure relative to the current DLPAR request.

The bindproc, softpset, and hardpset bits are only set, if the request is to remove a cpu. If the bindproc is set, the process or one of its threads has a bindprocessor attachment, which must be resolved. If the softpset bit is set, the process has a Workload Manager (WLM) attachment, which may be changed by calling the appropriate WLM interface or by invoking the appropriate WLM command. If the hardpset bit is set, the appropriate pset API should be used.

Note that the bcpu and lcpu fields identify the cpu being removed and do not necessarily indicate that the process has a dependency that must be resolved. The bindproc, softpset, and hardpset bits are provided for that purpose.

The plock and pshm bits are only set, if the request is to remove memory and the process has plock memory or is attached to a pinned shared memory segment. If the plock bit is set, the process should call plock to unpin itself. If the pshm bit is set, the application has pinned shared memory segments, which may need to be detached. The memory remove request may succeed in any case, if there is enough pinnable memory in the system, so an action in this case is not necessarily required. The field sys_pinnable_frames provides this information, however, this value and other statistical values are just approximations. They reflect the state of the system at the time of the request. They are not updated during the request. The current size of physical memory can be determined by referencing the _system_configuration.physmem field.

dr_info Structure

typedef struct dr_info {
    unsigned int add : 1,	// add request
	              rem : 1,	// remove request
	              cpu : 1,	// target resource is a cpu
	              mem : 1,	// target resource is memory
               check : 1,	// check phase in effect
	              pre : 1,	// pre phase in effect
	             post : 1,	// post phase in effect
           posterror : 1,	// post error phase in effect
	            force : 1,	// force option is in effect
      	   bindproc : 1,	// process has bindprocessor dependency
	         softpset : 1,	// process has WLM software partition dependency
	         hardpset : 1,	// process has processor set API dependency
	            plock : 1,	// process has plock'd memory
	             pshm : 1;	// process has pinned shared memory

    // The following fields are filled out for cpu based requests
    int lcpu;			// logical cpu ID being added or removed
    int bcpu;			// bind cpu ID being added or removed

    // The following fields are filled out for memory based requests
    size64_t  req_memsz_change;     // User request size in bytes            
    size64_t  sys_memsz;            // System Memory size at time of request 
    rpn64_t   sys_free_frames;      // Number of free frames in the system
    rpn64_t   sys_pinnable_frames;  // Number of pinnable frames in system
    rpn64_t   sys_total_frames;     // Total number of frames in system 

    int  reserved[12];
} dr_info_t;

Parameters

flags The following values are supported:
DR_QUERY
Identifies the current DLPAR request as well as the actions if any that the application should take to comply with with the current DLPAR request. This information is returned to the caller in the structure identified by the dr_info parameter.
DR_EVENT_FAIL
Fail the current DLPAR event. Root authority is required.
dr_info Contains the address of a dr_info structure, which is declared with the address space of the application.

Return Values

Upon success, the dr_reconfig system call returns a zero. If unsuccessful, it returns negative one and sets the errno variable to the appropriate error value.

Error Codes

EINVAL Invalid flags.
ENXIO No DLPAR event in progress.
EPERM Root authority required for DR_EVENT_FAIL.
EINPROGRESS Cancellation of DLPAR event may only occur in the check phase.

Related Information

Making Programs DLPAR-Aware Using DLPAR APIs in AIX 5L Version 5.2 General Programming Concepts: Writing and Debugging Programs.

[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]