hpux man page for numa_policy

numa_policy(5)							File Formats Manual						    numa_policy(5)

NAME
       numa_policy - physical memory allocation policy on cellular HP-UX servers

VALUES
   Default
   Allowed values
       Integer values or

DESCRIPTION
       HP-UX  treats  large servers as if they are built from componment blocks. Each component block is referred to as a locality and can contain
       memory, CPUs and peripherals. HP-UX constructs these component blocks in such a way as to optimize resource alignment.

       If a machine has only one locality, it is considered to be an UMA (Unform Memory Architecture) machine.	UMA is also a synonym for  Symmet-
       ric Multiprocessor (SMP).

       Large  servers  use  Non-Uniform Memory Access (NUMA) protocols.  An application thread can experience variable memory latency depending on
       whether it is accessing memory from the same locality upon which it is executing or from a different locality.

       HP-UX implements a number of memory allocation features to optimize performance.  Users can divide  the	memory	on  the  system  into  two
       classes of memory:  Interleaved and Cell-local.

       Interleaved  memory  delivers uniform latency.  It makes multiple localities look like a single bank of uniform memory, delivering the same
       average latency for all applications across all CPUs.  This is very useful in spreading the memory load across all the localities.

       Cell-local memory delivers low latency (high performance) to a process running in the same cell as the  memory  it  accesses.   Conversely,
       references from a remote cell will have a much higher latency.

       Users can configure cell-local memory using the HP-UX command or

       The  dynamic  kernel tunable allows users to define how interleaved and cell-local memory are utilized.	There are five possible values for
       this tunable:

	      This is the default value. HP-UX will autosense the right policy based on the
		     mode in which HP-UX is operating. See for more details on mode.

	      This is the default policy in LORA mode.
		     This policy directs HP-UX to use memory from the locality closest to the allocating CPU for user memory allocations.  It will
		     select  the  locality by first honoring any locality policies specified in or If no locality policies are specified, then all
		     memory is allocated from the locality closest to the allocating CPU.  See mpsched(1) for more information.

	      This policy directs HP-UX to override any locality policies supplied via
		     or and allocate all memory from the interleaved.  Cell-local memory is allocated when there is insufficient interleaved  mem-
		     ory.

	      This policy is like setting
		     to  except  that	all  text and library data segments are allocated from the interleaved domain.	This setting is useful for
		     servers running highly threaded applications.  This setting has a similar effect to the command's +id option (this option	is
		     only available on Integrity systems), but on a system wide basis.

	      This is the default policy in SMP mode.
		     In  a  machine configured with a mix of cell-local memory and interleaved memory, HP-UX makes intelligent decisions on how to
		     use the memory by distinguishing between private memory and shared memory. For example, Memory allocated to  private  objects
		     (stack, heap, private files, and so on) is likely to come from cell-local memory.	Memory allocated to shared objects (shared
		     files, System V shared memory) is allocated from interleaved memory unless the user specifies otherwise using  for  files	or
		     uses one of the memory options in

   Restrictions on Changing
       Changes	to  this  tunable  take  effect  on  memory  allocated	subsequent to the change. Any memory created before the change will not be
       affected.

   When Should the Value of This Tunable Be Changed to 1?
       should be set to 1 only if all performance-sensitive applications on the system have a high degree of locality of access.  That is, if  the
       majority  of references to shared memory are from processes running on the same cell where the memory has been allocated, then setting will
       have a positive effect on performance.  Changing the value to 1 should be done after sufficient memory has been	designated  as	cell-local
       using and the machine has been rebooted.

   When Should the Value of This Tunable Be Changed to 2?
       can  be	set  to  2  if the workload has a low degree of locality to a cell and it is not possible to change the source code.  Changing the
       value to 2 should be done after sufficient memory has been designated as interleaved using and the machine has been rebooted.  Setting  the
       tunable to 2 only makes sense in a mixed environment in which some applications can benefit from cell-local memory, and others cannot.

   When Should the Value of This Tunable Be Changed to 3?
       can  be	set to 3 if the all the performance-sensitive applications on the system have a high degree of locality of access and if the work-
       load is threaded.  Changing the value to 3 should be done after sufficient memory has been designated as cell-local using and  the  machine
       has been rebooted.

WARNINGS
       All  HP-UX kernel tunable parameters are release specific.  This parameter may be removed or have its meaning changed in future releases of
       HP-UX.

       Installation of optional kernel software, from HP or other vendors, may cause changes to tunable  parameter  values.   After  installation,
       some  tunable  parameters may no longer be at the default or recommended values.  For information about the effects of installation on tun-
       able values, consult the documentation for the kernel software being installed.	For information about optional kernel  software  that  was
       factory installed on your system, see at

AUTHOR
       was developed by HP.

SEE ALSO
       chatr_ia(1), mpsched(1), parmodify(1M), fadvise(2), shmget(2).

							     Tunable Kernel Parameters						    numa_policy(5)