HP-UX Reference (11i v1 00/12) - 2 System Calls (vol 5)

ManualsBrandsHP ManualsSoftwareHP-UX Reference Manuals

171

172

173

174

175

176

177

178

179

180

__________________________________________________________________________________________________________________________________________________________________________________________________

STANDARD Printed by: Nora Chuang [nchuang] STANDARD

/build/1111/BRICK/man2/!!!intro.2

________________________________________________________________

___ ___

mpctl(2) mpctl(2)

Processor Set Information

Warning: Dynamic creation and deletion of processor sets, and dynamic reassignment of a processor from

one processor set to another may occur. All processors in the system comprises one processor set by default

at boot time until new processor sets are created and conﬁgured by users. The following command requests

return topology information on processors and locality domains in the processor set of the calling thread.

For processor 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_GETNUMSPUS

This request returns the number of spus (processors) in the processor set of the cal-

ling thread. It may be zero if the processor set is empty. The spu and pid argu-

ments are ignored.

MPC_GETFIRSTSPU

This request returns the ID of the ﬁrst processor in the processor set of the calling

thread. The spu and pid arguments are ignored.

MPC_GETNEXTSPU

This request returns the ID of the next processor in the processor set of the calling

thread after spu. The pid argument is ignored.

Typically,

MPC_GETFIRSTSPU

is called to determine the ﬁrst spu.

MPC_GETNEXTSPU is then called in a loop (until the call returns -1) to determine

the IDs of the remaining spus.

For locality domain topology use:

int mpctl(mpc_request_t request, ldom_t ldom, pid_t pid);

The request argument determines the precise action to be taken by mpctl and is one of the following:

MPC_GETNUMLDOMS

This request returns the number of locality domains in the processor set of the cal-

ling thread. The ldom and pid arguments are ignored.

MPC_GETFIRSTLDOM

This request returns the ID of the ﬁrst locality domain in the processor set of the

calling thread. The ldom and pid arguments are ignored.

MPC_GETNEXTLDOM

This request returns the ID of the next locality domain in the processor set of the

calling thread after ldom. The pid argument is ignored.

Typically, MPC_GETFIRSTLDOM

is called to determine the ﬁrst locality domain.

MPC_GETNEXTLDOM is then called in a loop (until the call returns -1) to deter-

mine the IDs of the remaining locality domains.

MPC_LDOMSPUS This request returns the number of processors contributed by the locality domain

ldom to the processor set of the calling thread. It may be less than the total

number of processors in the ldom. 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. The binding assignments for a lightweight process do not

have to match the binding assignments for the process.

Setting the processor or locality domain binding on the process of a multithreaded process, causes all LWPs

(lightweight processes) in the target process to have their binding assignmentschanged to what is speciﬁed.

When a process creates another process (via fork() or vfork()), the child process will inherit the

parent process’s binding assignments (NOT the binding assignments of the fork’ing LWP). The initial LWP

in the child process shall inherit its binding assignments from the child process. LWPs other than the ini-

tial LWP shall inherit their binding assignments from the creating LWP (unless speciﬁed otherwise in the

LWP create attributes).

Processor binding and locality domain binding is mutually exclusive - only one can be in effect at any time.

If locality domain binding is in effect, the target is allowed to execute on any processor within that locality

Section 2−−164 − 3 − HP-UX Release 11i: December 2000

___