cpuset man page on IRIX

Man page or keyword search:  
man Server   31559 pages
apropos Keyword Search (all sections)
Output format
IRIX logo
[printable version]



cpuset(4)							     cpuset(4)

NAME
     cpuset, miser_cpuset - cpuset configuration files

DESCRIPTION
     A cpuset is defined by a cpuset configuration file and a name.  The
     cpuset configuration file is used to list the CPUs that are members of
     the cpuset and contains any additional parameters needed to define the
     cpuset.  The file permissions of the configuration file define access to
     the cpuset.  Every time permissions need to be checked, the current
     permissions of the file are used.	It is therefore possible to change
     access to a particular cpuset, without having to tear it down and
     recreate it, simply by changing the access permissions. Read access
     allows a user to retrieve information about a cpuset while execute
     permission allows the user to attach a process to the cpuset.

     The name of the cpuset is a three to eight character string.  Queue names
     having one or two characters are reserved for use by IRIX.

     For information on how to use cpusets in a Trusted IRIX environment, see
     the cpuset(1) man page.

EXAMPLE
     The following configuration file describes an exclusive cpuset containing
     8 CPUs:

     #cpuset configuration file
     EXCLUSIVE
     MEMORY_LOCAL
     MEMORY_EXCLUSIVE

     CPU 16
     CPU 17-19, 21, 23
     CPU 25
     CPU 27

     This specification will create a cpuset containing 8 CPUs, and will
     restrict those cpus to running threads that have been explicitly assigned
     to the cpuset.  Jobs running on the cpuset will use memory from nodes
     containing the cpus in the cpuset.	 Jobs running on other cpusets or on
     the global cpuset will not use memory from these nodes.

SUMMARY
     Commands are newline terminated, characters following the comment
     delimiter '#' are ignored, case matters, and tokens are separated by
     whitespace which is ignored.

     The valid tokens are:

     EXCLUSIVE
	  Defines a cpuset to be restricted.  It can occur anywhere in the
	  file.	 Anything else on the line is ignored.

									Page 1

cpuset(4)							     cpuset(4)

     EXPLICIT
	  By default, if a CPU is part of a cpuset the memory on the node
	  where the CPU is located is also part of the cpuset.	This flag
	  overrides the default behavior.  If this directive is present, the
	  nodes with memory that are to be included in the cpuset must be
	  specified using the MEM or NODE directives.

     MEMORY_LOCAL
	  Threads assigned to the cpuset will attempt to assign memory only
	  from nodes within the cpuset.	 Assignment of memory from outside the
	  cpuset will occur only if no free memory is available from within
	  the cpuset.  No restrictions are made on memory assignment to
	  threads running outside the cpuset.

     MEMORY_EXCLUSIVE
	  Threads not assigned to the cpuset will not use memory from within
	  the cpuset unless no memory outside the cpuset is available.

	  If, at the time a cpuset is created, memory is already assigned to
	  threads that are already running, no attempt will be made to
	  explicitly move this memory.	If page migration is enabled, the
	  pages will be migrated when the system detects that most references
	  to the pages are non-local.

     MEMORY_KERNEL_AVOID
	  The kernel will attempt to avoid allocating memory from nodes
	  contained in this cpuset.  If kernel memory requests cannot be
	  satisfied from outside this cpuset, this option will be ignored and
	  allocations will occur from within the cpuset.

	  WARNING: It is strongly recommended that this option not be used for
	  most cpuset configurations.  A side effect of this option is that
	  kernel memory allocations become concentrated on the remaining
	  system nodes, which may in turn degrade system performance.  This
	  option is effective only for certain workload patterns, and could
	  cause severe performance penalties in other situations.  It is
	  recommended that this option be used only when indicated by SGI
	  support.

	  Currently this option prevents only the system buffer cache from
	  being placed on the specified nodes.	Future IRIX releases may
	  expand the scope of this protection to exclude other kernel memory
	  allocations from the specified nodes.

	  This option was introduced in IRIX 6.5.7.

     MEMORY_MANDATORY
	  The kernel will limit all memory allocations to nodes that are
	  contained in this cpuset.  If memory requests cannot be satisfied,
	  the allocating process will sleep until memory is available.	The
	  process will be killed if no more memory can be allocated.  See
	  policies below.

									Page 2

cpuset(4)							     cpuset(4)

     POLICY_PAGE
	  Requires MEMORY_MANDATORY.  This is the default policy if no policy
	  is specified.	 This policy will cause the kernel to page user pages
	  to the swap file (see swap(1M)) to free physical memory on the nodes
	  contained in this cpuset.  If swap space is exhausted, the process
	  will be killed.

     POLICY_KILL
	  Requires MEMORY_MANDATORY.  The kernel will attempt to free as much
	  space as possible from kernel heaps, but will not page user pages to
	  the swap file.  If all physical memory on the nodes contained in
	  this cpuset are exhausted, the process will be killed.

     POLICY_SHARE_WARN
	  When creating a cpuset, if it is possible for the new cpuset to
	  share memory on a node with another cpuset the new cpuset will be
	  created but a warning message will be issued.	 POLICY_SHARE_WARN and
	  POLICY_SHARE_FAIL cannot be used together.

     POLICY_SHARE_FAIL
	  When creating a cpuset, if it is possible for the new cpuset to
	  share memory on a node with another cpuset the new cpuset will fail
	  to be created and an error message will be issued. POLICY_SHARE_WARN
	  and POLICY_SHARE_FAIL cannot be used together.

     CPU cpuid or cpuids
	  Specifies a single CPU or a list of CPUs that will be part of the
	  cpuset. The user can mix a single cpu line with a cpu list line.
	  For example:

	     CPU 2
	     CPU 3-4,5,7,9-12

     MEM nodeid or nodeids
	  Specifies a single node's memory or a list of nodes' memory that
	  will be part of the cpuset.  The specification of nodes follows the
	  same syntax as the CPU specification.

     NODE nodeid or nodeids
	  Specifies a single node's CPUs and memory, or a list of nodes' CPUs
	  and memory that will be part of the cpuset.  This directive is used
	  to specify that all node resources (CPU and memory) are to be
	  included in the cpuset.  The specification of nodes follows the same
	  syntax as the CPU specification.

     MEMORY_SIZE_ADVISORY size
	  Upon creation of a new cpuset, if the memory to be included is below
	  the specified size, a warning message will be issued and the cpuset
	  will continue to be created.	The value for size, is specified as an
	  integer suffixed by a size factor: B indicates bytes, K indicates

									Page 3

cpuset(4)							     cpuset(4)

	  kilobytes, M indicates megabytes, G indicates gigabytes, and T to
	  indicate terabytes.  MEMORY_SIZE_ADVISORY and MEMORY_SIZE_MANDATORY
	  can be used together.

	     MEMORY_SIZE_ADVISORY 130965K   # 130.964 MegaBytes
	     MEMORY_SIZE_ADVISORY 8192M	    # 8.192 GigaBytes
	     MEMORY_SIZE_ADVISORY 4G	    # 4 GigaBytes
	     MEMORY_SIZE_ADVISORY 1T	    # 1 TeraByte

     MEMORY_SIZE_MANDATORY size
	  Upon creation of a new cpuset, if the memory to be included is below
	  the specified size, an error message will be issued and the cpuset
	  will fail to be created.  The value for size, is specified as an
	  integer suffixed by a size factor: B indicates bytes, K indicates
	  kilobytes, M indicates megabytes, G indicates gigabytes, and T to
	  indicate terabytes.  MEMORY_SIZE_ADVISORY and MEMORY_SIZE_MANDATORY
	  can be used together.	 An example of the  syntax for specifying the
	  size is seen in the example for MEMORY_SIZE_ADVISORY.

     CPU_COUNT_ADVISORY count
	  Upon creation of a new cpuset, if the number of CPUs to be included
	  is below the specified count, a warning message will be issued and
	  the cpuset will continue to be created.  CPU_COUNT_ADVISORY and
	  CPU_COUNT_MANDATORY can be used together.  An example follows:

	     CPU_COUNT_ADVISORY 128  # If number CPUs < 128 warn

     CPU_COUNT_MANDATORY count
	  Upon creation of a new cpuset, if the number of CPUs to be included
	  is below the specified count, an error message will be issued and
	  the cpuset will fail to be created.  CPU_COUNT_ADVISORY and
	  CPU_COUNT_MANDATORY can be used together. An example follows:

	     CPU_COUNT_MANDATORY 96  # If number CPUs < 96 fail

NOTES
     In a cluster environment, the cpuset configuration file should reside on
     the root filesystem. If the cpuset configuration file resides on a
     filesystem other than the root filesystem and  you attempt to unmount the
     filesystem, the vnode for the cpuset remains active and the unmount (see
     mount(1M) command fails.

     Make sure that your workload manager sets the configuration file to
     reside on the root filesystem.

SEE ALSO
     cpuset(1), cpuset(5).

									Page 4

cpuset(4)							     cpuset(4)

     IRIX Admin: Resource Administration

									Page 5

[top]

List of man pages available for IRIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net