mpctl.2 (2010 09)

ManualsBrandsHP ManualsSoftwareHP-UX Manpages

mpctl(2) mpctl(2)

NAME

mpctl() - multiprocessor control

SYNOPSIS

#include <sys/mpctl.h>

int mpctl(

mpc_request_t request ,

spu_t spu,

pid_t pid

);

int mpctl(

mpc_request_t request ,

spu_t spu,

lwpid_t lwpid

);

int mpctl(

mpc_request_t request ,

ldom_t ldom,

pid_t pid

);

int mpctl(

mpc_request_t request ,

ldom_t ldom,

lwpid_t lwpid

);

Remarks

Much of the functionality of this capability is highly dependent on the underlying hardware. An applica-

tion that uses this system call should not be expected to be portable across architectures or implementa-

tions.

Some hardware platforms support online addition and deletion of processors. Due to this capability, pro-

cessors and locality domains may be added or deleted while the system is running. Applications should

be written to handle processor IDs and locality domain IDs that dynamically appear or disappear (for

example, sometime after obtaining the IDs of all the processors in the system an application may try to

bind an LWP to one of those processors - this system call will return an error if that processor had been

deleted).

Processor sets restrict application execution to a designated group of processors. Some applications may

query information about processors and locality domains available to them, while other applications may

require system-wide information. The

mpctl() interface supports two unique sets of command requests

for these purposes.

Applications using the pthread interfaces should not use this system call. A special set of

pthread_*()

routines has been developed for use by pthread applications. See the pthread_processor_bind_np(3T)

manual page for information on these interfaces.

DESCRIPTION

mpctl() provides a means of determining how many processors and locality domains are available in

the system, and assigning processes or lightweight processes to execute on speciﬁc processors or within a

speciﬁc locality domain.

A locality domain consists of a related collection of processors, memory, and peripheral resources that

comprise a fundamental building block of the system. All processors and peripheral devices in a given

locality domain have equal latency to the memory contained within that locality domain. Use

sys-

conf() with the _SC_CCNUMA_SUPPORT name to see if the ccNUMA functionality is enabled and

available on the system.

Processor sets provide an alternative application scheduling allocation domain. A processor set comprises

an isolated group of processors for exclusive use by applications assigned to the processor set. Applica-

tions may use

mpctl() to query about processors and locality domains available for them to scale and

optimize accordingly. Use sysconf() with _SC_PSET_SUPPORT name to see if the processor set func-

tionality is enabled and available on the system.

HP-UX 11i Version 3: September 2010 − 1 − Hewlett-Packard Company 1

Summary of content (12 pages)

PAGE 1
mpctl(2) mpctl(2) NAME mpctl() - multiprocessor control SYNOPSIS #include int mpctl( mpc_request_t request , spu_t spu , pid_t pid ); int mpctl( mpc_request_t request , spu_t spu , lwpid_t lwpid ); int mpctl( mpc_request_t request , ldom_t ldom , pid_t pid ); int mpctl( mpc_request_t request , ldom_t ldom , lwpid_t lwpid ); Remarks Much of the functionality of this capability is highly dependent on the underlying hardware.
PAGE 2
mpctl(2) mpctl(2) The mpctl() call is expected to be used to increase performance in certain applications, but should not be used to ensure correctness of an application. Specifically, cooperating processes/lightweight processes should not rely on processor or locality domain assignment in lieu of a synchronization mechanism (such as semaphores). Machine Topology Information Warning: Processor and locality domain IDs are not guaranteed to exist in numerical order.
PAGE 3
mpctl(2) mpctl(2) (NOT the ldom assignment of the caller). The ldom and pid arguments are ignored. Warning: The information returned by this system call may be out-of-date arbitrarily soon after the call completes due to the scheduler context switching the caller onto a different ldom. MPC_LDOMSPUS_SYS This request returns the number of enabled processors in the locality domain ldom. The pid argument is ignored. MPC_SPUTOLDOM This request returns the ID of the locality domain containing processor spu .
PAGE 4
mpctl(2) mpctl(2) MPC_GETFIRSTPROXIMATESPU This request returns the ID of the first enabled processor which is in the processor set of the calling thread and is proximate to spu . Even when spu is enabled, the return value will be -1 if none of the proximate processors contribute to the processor set of the calling thread. If spu is not enabled, -1 is returned. The pid argument is ignored.
PAGE 5
mpctl(2) mpctl(2) Processor Socket Information For processor socket topology use: int mpctl(mpc_request_t request, spu_t spu, pid_t pid); The request argument determines the precise action to be taken by mpctl() and is one of the following: MPC_GETNUMSOCKETS_SYS This request returns the number of enabled sockets (physical processors) in the system. An enabled socket has at least one core enabled. The value will be greater than or equal to 1. If the call is not implemented the value will be -1.
PAGE 6
mpctl(2) mpctl(2) MPC_LDOMCORES Returns the number of enabled processor cores assigned to the current processor set in the locality domain; this value will always be greater than or equal to 0. The pid argument is ignored. Processor and Locality Domain Binding Each process shall have a processor and locality domain binding. Each LWP (lightweight process) shall have a processor and locality domain binding.
PAGE 7
mpctl(2) mpctl(2) process will not be selected to execute on the selecting processor, but instead wait for the specified processor to which it was bound. The selecting processor will then choose a lower priority process to execute on the processor. NOTE: This option will not guarantee compliance with POSIX real-time scheduling algorithms.
PAGE 8
mpctl(2) mpctl(2) If the process specified by pid is a multithreaded process, all LWPs (lightweight processes) in the target process will have their locality domain assignment changed to what is specified. However, if any LWP belongs to a processor set different from the target process, and if the specified locality domain does not contribute any processor to that locality domain, the binding assignment of such an LWP is not changed.
PAGE 9
mpctl(2) mpctl(2) Current valid return values are MPC_NO_BINDING (no binding), MPC_SPU_BINDING (advisory processor binding), MPC_SPU_FORCED_BINDING (processor binding), and MPC_LDOM_BINDING (locality domain binding). Other binding types may be added in future releases and returned via this option. Applications using this option should be written to handle other return values in order to continue working on future releases. Launch Policies Each process shall have a launch policy.
PAGE 10
mpctl(2) mpctl(2) If the processor set binding for a process or an LWP in a launch tree is changed to another processor set, that process or LWP becomes the root of a new launch tree. When creating a new process or an LWP, if the root of the launch tree is found to be in a different processor set, the new process or LWP is made the root of a new launch tree. NOTE: locality domains are tightly tied to the physical components of the underlying system.
PAGE 11
mpctl(2) mpctl(2) launch tree. This launch policy includes all descendents of the target process in the launch tree. The ldom argument is ignored. MPC_SETPROCESS_NONE This call unsets any launch policy in the process. The system will employ a default, optimal policy in determining where the newly created process will be launched. The existing binding of the process is not changed. The ldom argument is ignored.
PAGE 12
mpctl(2) mpctl(2) default, optimal policy in determining where the newly created LWP will be launched. The existing binding of the LWP is not changed. The ldom argument is ignored. To change the processor assignment, locality domain assignment, or launch policy of another process, the caller must either have the same effective user ID as the target process, or have the PRIV_MPCTL privilege. Security Restrictions Some or all of the actions associated with this system call require the MPCTL privilege.