Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

numa_scheduling_groups(4) [osf1 man page]

numa_scheduling_groups(4)				     Kernel Interfaces Manual					 numa_scheduling_groups(4)

NAME

       numa_scheduling_groups - Compaq Tru64 UNIX NUMA Scheduling Groups description (libnuma library)

DESCRIPTION

       Normally,  the  kernel  scheduler  attempts to distribute the workload evenly over the entire machine. When the system resources are evenly
       utilized, the machine is considered to be balanced. When balancing the workload, the scheduler operates in a context-free manner; that  is,
       processes  may be distributed to various CPUs, or other resources, without regard to their function or relationship to one another. In cer-
       tain cases, a user may wish to bundle a group of processes together so that they have equal  access  to	the  same  system  resources.  For
       instance,  cooperating  processes that share the same physical memory may perform better if all of these processes execute on CPUs that are
       local to that memory.

       NUMA Scheduling Groups (NSG) cause the scheduler load-balancing system to treat all members of an NSG as a unit. If one	process  belonging
       to an NSG moves from one Resource Affinity Domain (RAD) to another, all other members of the NSG have to move with it.

       NSGs  and  their  members  have the following characteristics: The resource domain of the first process joining an NSG provides the initial
       resource domain location for that NSG, called the NSG home RAD.	All other processes joining the NSG (through  the  nsg_attach_pid()  func-
       tion) will be migrated to the NSG home RAD.  If the joining process is not allowed to migrate, the nsg_attach_pid() function will fail.	To
       support load balancing, an NSG is allowed to migrate to any RAD on the system if none of its members is bound to a specific resource  (such
       as another RAD, CPU, and so on).  An NSG member is allowed to attach to or bind to a resource only if no other members are bound to differ-
       ent resources. The entire NSG will migrate to the RAD containing the resource at the time it was successfully bound.  If one NSG member	is
       bound  to  a resource, all other members of that NSG are also bound to the RAD containing that resource, because the NSG and, therefore its
       members, is no longer allowed to migrate.

SEE ALSO

       Commands: runon(1)

       Functions: bind_to_cpu(3), nsg_attach_pid(3), nsg_detach_pid(3),  nsg_destroy(3),  nsg_get(3),  nsg_get_pids(3),  nsg_init(3),  nsg_set(3),
       numa_intro(3), rad_attach_pid(3), rad_bind_pid(3), rad_detach_pid(3)

															 numa_scheduling_groups(4)

Check Out this Related Man Page

rad_fork(3)						     Library Functions Manual						       rad_fork(3)

NAME

       rad_fork - Creates a new process on a Resource Affinity Domain (libnuma library)

SYNOPSIS

       #include <numa.h>

       pid_t rad_fork(
	       radid_t radid,
	       ulong_t flags );

PARAMETERS

       Identifies  a  Resource	Affinity  Domain (RAD) on which to allocate data and schedule threads for a new process.  Specifies options (a bit
       mask) that affect the attachment or binding operation. See DESCRIPTION for details.

DESCRIPTION

       The rad_fork() function behaves the same as nfork() when the latter specifies a resource type of  R_RAD	and  a	resource  descriptor  that
       points  to a RAD set containing a single RAD identifier. For a description of this behavior, refer to the description of the R_RAD resource
       type in nfork(3).

       The following option is specified for the flags argument: This option specifies that any processes later forked by  the	specified  process
       will not inherit the parent's RAD assignment.

	      By default, any child processes will be assigned to the same home RAD as their parent process, and will be attached or bound to that
	      RAD if the parent was attached or bound.

RETURN VALUES

       Success (returned to the child process). In this case, the function also returns the process ID of the child process to the parent process.

	      The child process and all of its data structures are allocated on the RAD specified by the radid argument. In addition, the  initial
	      thread  of the child process is sceduled on one of the CPUs in the specified RAD.  Failure (returned to the parent process). In this
	      case, no child process is created and the function sets errno to indicate the error.

ERRORS

       The limit on the total number of processes executing for a single user would be exceeded. This limit can be  exceeded  by  a  process  with
       superuser privilege.  The radid argument specifies an invalid RAD identifier.  There is insufficient memory to create this process.

SEE ALSO

       Functions: nfork(3), nloc(3), numa_intro(3), radsetops(3)

       Files: numa_types(4)

																       rad_fork(3)
Man Page