Appendix A. IRIX Kernel Tunable Parameters
Prev |  | Next

## Appendix A. IRIX Kernel Tunable Parameters

This appendix describes the tunable parameters that define kernel structures. These structures keep track of processes, files, and system activity. Many of the parameter values are specified in the files found in `/var/sysgen/mtune` and `/var/sysgen/master.d`.

If the system does not respond favorably to your tuning changes, you may want to return to your original configuration or continue making changes to related parameters. An unfavorable response to your tuning changes can be as minor as the system not gaining the hoped-for speed or capacity, or as major as the system becoming unable to boot or run. This generally occurs when parameters are changed to a great degree. Simply maximizing a particular parameter without regard for related parameters can upset the balance of the system to the point of inoperability. For complete information on the proper procedure for tuning your operating system, read Chapter 10, “System Performance Tuning”.

The rest of this appendix describes the more important tunable parameters according to function. Related parameters are grouped into sections. These sections include:

- General tunable parameters. See “ General Parameters”.

- System limits tunable parameters. See “ System Limits Parameters”.

- Resource limits tunable parameters. See “ Resource Limits Parameters”.

- Paging tunable parameters. See “ Paging Parameters”.

- IPC tunable parameters–including interprocess communication messages, semaphores, and shared memory. See “IPC Parameters”, “IPC Messages Parameters”, “IPC Semaphores Parameters”, and “IPC Shared Memory Parameters”.

- Streams tunable parameters. See “Streams Parameters”.

- Signal parameters. See “Signal Parameter”.

- Dispatch parameters. See “Dispatch Parameters”.

- Extent File System (EFS) parameters. See “Filesystem Parameters”.

- Loadable driver parameters. See “Loadable Drivers Parameters”.

- CPU actions parameters. See “CPU Action Parameter”.

- Switch parameters. See “Switch Parameters”.

- Timer parameters. See “Timer Parameters”.

- Network File System (NFS) parameters. See “NFS Parameters”.

- Socket parameters. See “Socket Parameters”.

- Indy Video parameters. See “VINO Parameter”.

- Large page parameters. See “Large Page Parameters”.

- Extended accounting parameters. See “Extended Accounting Parameters”.

- NUMA parameters. See “NUMA Parameters”.

- Page replication parameters. See “Page Replication Parameter”.

- Migration memory queue parameters. See “Migration Memory Queue Parameters”.

- XVM parameters. See “XVM Parameters”.

- CXFS parameters. See “CXFS Parameters”.

- Core file parameters. See “Core File Parameter”.

Each section begins with a short description of the activities controlled by the parameters in that section, and each listed parameter has a description that may include the following parts:

Name |  | Specifies the name of the parameter.
Description |  | Provides a description of the parameter, including the file in which the parameter is specified, and the formula, if applicable.
Value |  | Gives the default setting and, if applicable, a range. Note that the value given for each parameter is usually appropriate for a single-user graphics workstation. Values may be presented in either hex or decimal notation.
When to Change |  | Discusses the conditions under which it is appropriate to change the parameter.
Notes |  | Covers other pertinent information, such as error messages.

Note that the tunable parameters are subject to change with each release of the system.

## General Parameters

The following group of tunable parameters specifies the size of various system structures. These are the parameters you will most likely change when you tune a system.

- `cachefs_readahead` specifies the number of readahead blocks for the filesystem.

- `cachefs_max_threads` specifies the maximum number of asynchronous I/O daemons per cachefs mount.

- `nbuf` specifies the number of buffer headers in the filesystem buffer cache.

- `min_bufmem` specifies the minimum amount of memory held by filesystem metadata that is cached in the buffer cache when the system runs into low memory conditions.

- `callout_himark` specifies the high water mark for callouts.

- `ncallout` specifies the initial number of callouts.

- `reserve_ncallout` specifies the number of reserved callouts.

- `ncsize` specifies the name cache size.

- `ndquot` used by the disk quota system.

- `nproc` specifies the number of user processes allowed at any given time.

- `maxpmem` specifies the maximum physical memory address.

- `syssegsz` specifies the maximum number of pages of dynamic system memory.

- `maxdmasz` specifies the maximum DMA transfer in pages.

- `mbmaxpages` specifies the maximum number of one-page clusters used in network buffers.

- `ecc_recover_enable` specifies the system response to multibit errors.

- `utrace_bufsize` selects the number of 48 byte `utrace` entries stored for each CPU.

- `dump_level` specifies the dump level.

- `buf_relse_age` specifies when a buffer cache page needs to be released.

### `cachefs_readahead`

Description |  | The `cachefs_readahead` parameter specifies the number of blocks to read ahead of the current read block in the filesystem. The blocks are read asynchronously.
Value |  | Default: 1 (0x1) Range: 0 - 10

### `cachefs_max_threads`

Description |  | The `cachefs_max_threads` parameter specifies the maximum number of asynchronous I/O daemons that can be run per cachefs mount.
Value |  | Default: 5 (0x5) Range: 1 - 10

### `nbuf`

Description |  | The `nbuf` parameter specifies the number of buffer headers in the filesystem buffer cache. The actual memory associated with each buffer header is dynamically allocated as needed. The memory can be of varying size: 1 to 128 blocks (512 to 64KB) for write operations, and 1 to 1024 blocks (512 to 512KB) for read operations. The system uses the filesystem buffer cache to optimize filesystem I/O requests. The buffer memory caches blocks from the disk, and the blocks that are used frequently stay in the cache. This helps avoid excess disk activity. Buffers are used only as transaction headers. When the input or output operation has finished, the buffer is detached from the memory it mapped and the buffer header becomes available for other uses. Because of this, a small number of buffer headers is sufficient for most systems. If `nbuf` is set to 0, the system automatically configures `nbuf` for average systems. There is little overhead in making it larger for non-average systems. The `nbuf` parameter is defined in `/var/sysgen/mtune`.
Value |  | Default: 0 (Automatically configured if set to 0) Formula: 32-bit kernels: min(100 + (KiloBytes of memory) / 160, 6000) 64-bit kernels: min(100 + (KiloBytes of memory) / 160, 600000)
When To Change |  | The automatic configuration is adequate for average systems. If you see dropping cache-hit rates in `sar` and `osview` output, increase this parameter. Also, if you have directories with a great number of files (over 1000), you may wish to raise this parameter. The recommended initial value for large (64 processors or greater) systems is 2000.

### `min_bufmem`

Description |  | The `min_bufmem` parameter specifies the minimum amount of memory held by filesystem metadata that is cached in the buffer cache when the system runs into low memory conditions. This is expressed in pages of memory.
Value |  | Default: two percent of physical memory
When To Change |  | Change this value when there is a high I/O load on your machine but you still need to access directory information quickly.

### `callout_himark`

Description |  | The `callout_himark` parameter specifies the maximum number of callout table entries system-wide. The callout table is used by device drivers to provide a timeout to make sure that the system does not hang when a device does not respond to commands. This parameter is defined in `/var/sysgen/mtune` and has the following formula: `nproc` + 32 where: `nproc` is the maximum number of processes, system-wide.
Value |  | Default: 0 (Automatically configured if set to 0) Formula: `nproc` + 32 Range: 42 - 1100
When to Change |  | Increase this parameter if you see console error messages indicating that no more callouts are available.

### `ncallout`

Description |  | The `ncallout` parameter specifies the number of callout table entries at boot time. The system will automatically allocate one new callout entry if it runs out of entries in the callout table. However, the maximum number of entries in the callout table is defined by the `callout_himark` parameter.
Value |  | Default: 40 Range: 20–1000
When to Change |  | Update `ncallout` if you are running an unusually high number of device drivers on your system. Note that the system automatically allocates additional entries when needed, and releases them when they are no longer needed.

### `reserve_ncallout`

Description |  | The `reserve_ncallout` parameter specifies the number of reserved callout table entries. These reserved table entries exist for kernel interrupt routines when the system has run out of the normal callout table entries and cannot allocate additional entries.
Value |  | Default: 5 Range: 0-30

### `ncsize`

Description |  | The `ncsize` parameter controls the size of the name cache. The name cache is used to allow the system to bypass reading directory names out of the main buffer cache. A name cache entry contains a directory name, a pointer to the directory's in-core inode and version numbers, and a similar pointer to the directory's parent directory in-core inode and version number.
Value |  | Default: 0 (Automatically configured if set to 0) Range: 268-1M

### `ndquot`

Description |  | The `ndquot` parameter controls disk quotas.
Value |  | Default: 0 (Automatically configured if set to 0) Range: 268-6200

### `nproc`

Description |  | The `nproc` parameter specifies the number of entries in the system process (`proc`) table. Each running process requires an in-core `proc` structure. Thus, `nproc` is the maximum number of processes that can exist in the system at any given time. The default value of `nproc` is based on the amount of memory on your system. To find the currently auto-configured value of `nproc`, use the `systune` command. The `nproc` parameter is defined in `/var/sysgen/mtune`.
Value |  | Default: 0 (Automatically configured if set to 0) Range: 30-1M
When to Change |  | Increase this parameter if you see an overflow in the `sar -v` output for the `proc -sz ov` column or you receive the operating system message:
    no more processes
This means that the total number of processes in the system has reached the current setting. If processes are prevented from forking (being created), increase this parameter. A related parameter is `maxup`. The recommended initial value for large (64 processors or greater) systems is 8000.
Notes |  | If a process cannot fork, make sure that this is system-wide and not just a user ID problem (see the `maxup` parameter). If `nproc` is too small, processes that try to fork receive the operating system error:
    EAGAIN: No more processes
The shell also returns a message:
    fork failed: too many processes
If a system daemon such as `sched`, `vhand`, `init`, or `bdflush` cannot allocate a process table entry, the system halts and displays:
    No process slots

### `maxpmem`

Description |  | The `maxpmem` parameter specifies the amount of physical memory (in pages) that the system can recognize. The page size is 4 KB for 32 bit IRIX version 5 or 6 kernels and 16 KB for 64 bit IRIX version 6 kernels. If it is set to zero (0), the system will use all available pages in memory. A value other than zero defines the physical memory size (in pages) that the system will recognize. This parameter is defined in `/var/sysgen/mtune`.
Value |  | Default: 0 (Automatically configured if set to 0) Range: 1024 pages—total amount of memory
When to Change |  | You do not need to change this parameter, except when benchmarks require a specific system memory size less than the physical memory size of the system. This is primarily useful to kernel developers. You can also boot the system with this command added on the `boot` command line to achieve the same effect:
    maxpmem = memory_size

### `syssegsz`

Description |  | The `syssegez` parameter specifies the maximum number of pages of dynamic system memory.
Value |  | Default: 0 (Autoconfigured if set to 0) 32-bit Range: 0x2000 - 0x20000 64-bit Range: 0x2000 - 0x10000000
When to Change |  | Increase this parameter correspondingly when `maxdmasz` is increased, or when you install a kernel driver that performs a lot of dynamic memory allocation. The recommended initial value for large (64 processors or greater) systems is 0xfe800.

### `maxdmasz`

Description |  | The `maxdmasz` parameter specifies the maximum DMA transfer expressed in pages of memory. This amount must be less than the value of `syssegsz` and `maxpmem`.
Value |  | Default: 1025 (32-bit kernels) Default: 257 (64-bit kernels) 32-bit Range: 1 - `syssegsz` (maximum 0x20000) 64-bit Range: 1 - `syssegsz` (maximum 0x10000000)
When to Change |  | Change this parameter when you need to be able to use very large read or write system calls, or other system calls that perform large scale DMA. This situation typically arises when using optical scanners, film recorders or some printers. Note that the actual DMA transfer size is one less page than the number of pages set in this parameter. Thus, to allow a full DMA transfer of 16 MB (1024 pages), set this parameter to 1025. The recommended initial value for large (64 processors or greater) systems is 0x2001.

### `mbmaxpages`

Description |  | The `mbmaxpages` parameter specifies the maximum number of single page clusters that can be allocated to network buffers. This limits the total memory that network buffers (mbufs) can consume.
Value |  | Default: 1/4 of physical memory Range: Default - Total System Memory (in pages)
When to Change |  | For most workstations and small servers the default is sufficient. For very large systems, larger values are appropriate. A 0 value tells the kernel to set the value (1/4 of physical memory) based on the amount of physical memory configured in the hardware. The minimum that can be set with the `systune` command is 16 pages. The maximum is 8192 pages for 32-bit systems and 2097152 pages for 64-bit systems.

### `ecc_recover_enable`

Description |  | The `ecc_recover_enable` parameter, when set to 0, directs the system not to attempt to recover from multibit errors. If it is set greater than 0, the parameter value is taken as a number of seconds. The system is directed to attempt recovery, but not in the event of more than 32 errors in each number of seconds specified by this parameter.
Value |  | Default: 60 seconds (0x3c)

### `utrace_bufsize`

Description |  | `utraces` are a lightweight tracing mechanism used to collect kernel debugging information. The `utrace_bufsize` parameter selects the number of 48 byte `utrace` entries stored for each CPU. Setting this parameter to 0 disables trace collection. Only buffer sizes of 0 and 2048 are supported.
Value |  | Default: 0 Range: 0-0x7fffffff

### `dump_level`

Description |  | The `dump_level` parameter specifies the dump level and controls the data dumped in a system crash. Setting this parameter to 0 dumps only `putbuf,``errbuf`, and low memory during a panic. 1 also dumps static, dynamic, and backtrace kernel pages along with `pfdats` (if applicable); 2 also dumps buffer cache pages; 3 also dump remaining in-use pages; and 4 also dumps free pages.
Value |  | Default: 0 Range: 0-4 The recommended initial value for large (64 processors or greater) systems is 3.

### `buf_relse_age`

Description |  | The `buf_relse_age` parameter specifies when a buffer cache page needs to be released. If a file's data had been untouched for at least `buf_relse_age` seconds, then the data is released. This run-time settable variable may be useful in systems in which some nodes have plenty of free memory and others have consumed all local memory. If the latter contains a lot of very aged buffer cache data, the normal buffer releasing system may not release the data because the system looks at memory globally and does not distinguish memory per node.
Value |  | Default: 0 (0 means the feature is not used.) Range: 0-0x7fffffff seconds
When to Change |  | A recommended setting is difficult to provide as the load and needs of every system are different. Any setting under 30 seconds is too aggressive, and any under 10 seconds causes a lot of thrashing. A workable solution is to set `buf_relse_age` to 600 seconds (5 minutes), to study the displays of the `bufview` and `osview` commands over time in order to observe how much memory is available, and then to adjust the `buf_relse_age` value up or down until it appears to be satisfactory.

## System Limits Parameters

The IRIX system has configurable parameters for certain system limits. For example, you can set maximum values for each process (its core or file size), the number of groups per user, the number of resident pages, and so forth. These parameters are listed below. All parameters are set and defined in `/var/sysgen/mtune/kernel`.

- `maxup` specifies the number of processes per user.

- `ngroups_max` specifies the number of groups to which a user may belong.

- `maxwatchpoints` specifies the maximum number of watchpoints per process.

- `` specifies amount of disjoint text space to be profiled.

- `maxsymlinks` specifies the maximum number of symlinks expanded in a pathname.

### `maxup`

Description |  | The `maxup` parameter defines the number of processes allowed per user login. This value should always be at least 20 less than `nproc`.
Value |  | Default: 150 processes Range: 15–30000 (but never more than `nproc` minus 20)
When to Change |  | Increase this parameter to allow more processes per user. In a heavily loaded time-sharing environment, you may want to decrease the value to reduce the number of processes per user. The recommended initial value for large (64 processors or greater) systems is 8000.

### `ngroups_max`

Description |  | The `ngroups_max` parameter specifies the maximum number of multiple groups to which a user may simultaneously belong. The constants `NGROUPS_UMIN` <= ngroups_max <= `NGROUPS_UMAX` are defined in <`/usr/include/sys/param.h`>. `NGROUPS_UMIN` is the minimum number of multiple groups that can be selected at `lboot` time. `NGROUPS_UMAX` is the maximum number of multiple groups that can be selected at `lboot` time and is the number of group-id slots for which space is set aside at compile time. `NGROUPS`, which is present for compatibility with networking code (defined in <`/usr/include/sys/param.h`>), must not be larger than `ngroups_max`.
Value |  | Default: 16 Range: 0-32
When to Change |  | The default value is adequate for most systems. Increase this parameter if your system has users who need simultaneous access to more than 16 groups.

### `maxwatchpoints`

Description |  | The `maxwatchpoints` parameter sets the maximum number of watchpoints per process. Watchpoints are set and used via the proc(4) filesystem. This parameter specifies the maximum number of virtual address segments to be watched in the traced process. This is typically used by debuggers.
Value |  | Default: 100 Range: 1-1000
When to Change |  | Raise `maxwatchpoints` if your debugger is running out of watchpoints.

### `nprofile`

Description |  | The `nprofile` parameter specifies the maximum number of disjoint text spaces that can be profiled using the `sprofil(2)` system call. This is useful if you need to profile programs using shared libraries or profile an address space using different granularities for different sections of text.
Value |  | Default: 100 Range: 100-10000
When to Change |  | Change `nprofile` if you need to profile more text spaces than are currently configured.

### `maxsymlinks`

Description |  | The `maxsymlinks` parameter defines the maximum number of symbolic links that will be followed during filename lookups (for example, during the `open(2)` or `stat(2)` system calls) before ceasing the lookup. This limit is required to prevent loops where a chain of symbolic links points back to the original filename.
Value |  | Default: 30 Range: 0-50
When to Change |  | Change this parameter if you have pathnames with more than 30 symbolic links.

## Resource Limits Parameters

You can set numerous limits on a per-process basis by using `getrlimit(2)`, `setrlimit(2)`, and `limit`, the shell built-in command. These limits are inherited, and the original values are set in `/var/sysgen/mtune`. These limits are different from the system limits listed above in that they apply only to the current process and any child processes that may be spawned. To achieve similar effects, you can also use the `limit` command within the Bourne, C, and Korn shells (`/bin/sh`, `/bin/csh`, and `/bin/ksh`). For additional information on resource limits, see IRIX Admin: Resource Administration.

Each limit has a default and a maximum. Only the superuser can change the maximum. Each resource can have a value that turns off any checking. The default values are adequate for most systems.

| Note: Resource limit values (`rlim_t`) are 64-bit in both n32 and n64 binaries. Consequently, n32 binaries can set 64-bit limits. o32 binaries cannot set 64-bit limits because `rlim_t` is 32-bits in o32 binaries. IRIX supports three Application Binary Interfaces (ABIs): o32, n64, and n32 (for more information on ABIs, see the `abi`(5) man page).

The following parameters are associated with system resource limits:

- `ncargs` specifies the number of bytes of arguments that may be passed during an `exec(2)` call.

- `rlimit_core_cur` specifies the current size of a core file.

- `rlimit_core_max` specifies the maximum value `rlimit_core_cur` may hold.

- `rlimit_cpu_cur` specifies the limit for current CPU time available to a process.

- `rlimit_cpu_max` specifies the maximum value `rlimit_cpu_cur` may hold.

- `rlimit_data_cur` specifies the current amount of data space available to a process.

- `rlimit_data_max` specifies the maximum value `rlimit_data_cur` may hold.

- `rlimit_fsize_cur` specifies the current file size available to a process.

- `rlimit_fsize_max` specifies the maximum value `rlimit_fsize_cur` may hold.

- `rlimit_nofile_cur` specifies the current number of file descriptors available to a process.

- `rlimit_nofile_max` specifies the maximum value `rlimit_nofile_cur` may hold.

- `rlimit_pthread_cur` specifies the current amount of threads that a process creates.

- `rlimit_pthread_max` specifies the maximum value `rlimit_pthread_cur` may hold.

- `rlimit_rss_cur` specifies the current resident set size available to a process.

- `rlimit_rss_max` specifies the maximum value `rlimit_rss_cur` may hold.

- `rlimit_stack_cur` specifies the current stack size for a process.

- `rlimit_stack_max` specifies the maximum value `rlimit_stack_cu` r may hold.

- `rlimit_vmem_cur` specifies the current amount of virtual memory for a process.

- `rlimit_vmem_max` specifies the maximum value `rlimit_vmem_cur` may hold.

- `rsshogfrac` specifies the percentage of memory allotted for resident pages.

- `rsshogslop` specifies the number of pages above the resident set maximum that a process may use.

- `shlbmax` specifies the maximum number of shared libraries with which a process can link.

- `cpulimit_gracetime` establishes a grace period for processes that exceed the cpu time limit.

### `ncargs`

Description |  | The `ncarg` s parameter specifies the maximum size of arguments in bytes that may be passed during an `exec(2)` system call. This parameter is specified in `/var/sysgen/mtune`.
Value |  | Default: 20480 Range: 5120–262144
When to Change |  | The default value is adequate for most systems. Increase this parameter if you get the following message from `exec(2)`, `shell(1)`, or `make(1)`:
    E2BIG arg list too long
Notes |  | Setting this parameter too large wastes memory (although this memory is pageable) and may cause some programs to function incorrectly. Also note that some shells may have independent limits smaller than `ncargs`.

### `rlimit_core_cur`

Description |  | The `rlimit_core_cur` parameter specifies the current limit to the size of core image files for the given process.
Value |  | Default: 0x7fffffffffffffff (9223372036854775807 bytes) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a cap on core file size.

### `rlimit_core_max`

Description |  | The `rlimit_core_max` parameter specifies the maximum limit to the size of core image files.
Value |  | Default: 0x7fffffffffffffff (9223372036854775807 bytes) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a maximum restriction on core file size. `rlimit_core_cur` cannot be larger than this value.

### `rlimit_cpu_cur`

Description |  | The `rlimit_cpu_cur` parameter specifies the current limit to the amount of CPU time in seconds that may be used in executing the process.
Value |  | Default: 0x7fffffffffffffff (9223372036854775807 seconds) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a cap on CPU usage.

### `rlimit_cpu_max`

Description |  | The `rlimit_cpu_max` parameter specifies the maximum limit to the amount of CPU time that may be used in executing a process.
Value |  | Default: 0x7fffffffffffffff (9223372036854775807 minutes) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a maximum restriction on general CPU usage.

### `rlimit_data_cur`

Description |  | The `rlimit_data_cur` parameter specifies the current limit to the data size of the process.
Value |  | Default: 0 (auto-configured to rlimit_vmem_cur * NBPP) (0x20000000) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a cap on data segment size. The recommended initial value for large (64 processors or greater) systems is 0 ll.

### `rlimit_data_max`

Description |  | The `rlimit_data_max` parameter specifies the maximum limit to the size of data that may be used in executing a process.
Value |  | Default: 0 (auto-configured to rlimit_vmem_cur * NBPP) (0x20000000) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a maximum restriction on the size of the data segment of any process. The recommended initial value for large (64 processors or greater) systems is 0 ll.

### `rlimit_fsize_cur`

Description |  | The `rlimit_fsize_cur` parameter specifies the current limit to file size on the system for the process.
Value |  | Default: 0x7fffffffffffffff (9223372036854775807 bytes) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a limit on file size.

### `rlimit_fsize_max`

Description |  | The `rlimit_fsize_max` parameter specifies the maximum limit to file size on the system.
Value |  | Default: 0x7fffffffffffffff (9223372036854775807 bytes) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a maximum size on all files.

### `rlimit_nofile_cur`

Description |  | The `rlimit_nofile_cur` parameter specifies the current limit to the number of open file descriptors that may be used in executing the process.
Value |  | Default: 200 Range: 40–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a cap on the number of open file descriptors.

### `rlimit_nofile_max`

Description |  | The `rlimit_nofile_max` parameter specifies the maximum limit to the number of open file descriptors that may be used in executing a process.
Value |  | Default: 2500 Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a maximum restriction on the number of open file descriptors.

### `rlimit_pthread_cur`

Description |  | The `rlimit_``pthread_cur` parameter specifies the current amount of threads that a process creates.
Value |  | Default: 1024 (0x400)

### `rlimit_pthread_max`

Description |  | The `rlimit_``pthread_``max` parameter specifies the maximum value `rlimit_pthread_cur` may hold.
Value |  | Default: 1024 (0x400)

### `rlimit_rss_cur`

Description |  | The `rlimit_rss_cur` parameter specifies the current limit to the resident set size (the number of pages of memory in use at any given time) that may be used in executing the process. This limit is the larger of the results of the following two formulae: physical_memory_size - 4 MB physical_memory_size * 9/10
Value |  | Default: 0. If `rlimit_rss_cur` is 0, it is automatically configured to the larger of the following formulae:
      physical_memory_size - 4 MB
      physical_memory_size * 9/10)
Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a cap on the resident set size of a process. The recommended initial value for large (64 processors or greater) systems is 0 ll.

### `rlimit_rss_max`

Description |  | The `rlimit_rss_max` parameter specifies the maximum limit to the resident set size that may be used in executing a process.
Value |  | Default: 0. If `rlimit_rss_max` is 0, it is automatically configured to the larger of the following formulae:
      physical_memory_size - 4 MB
      physical_memory_size * 9/10)
Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a maximum restriction on resident set size. The recommended initial value for large (64 processors or greater) systems is 0 ll.

### `rlimit_stack_cur`

Description |  | The `rlimit_stack_cur` parameter specifies the current limit to the amount of stack space that may be used in executing the process.
Value |  | Default: 64 MB (0x04000000) Range: 0–0x7fffffffffffffff)
When to change |  | Change this parameter when you want to place a limit on stack space usage. The recommended initial value for large (64 processors or greater) systems is (0x04000000) ll.

### `rlimit_stack_max`

Description |  | The `rlimit_stack_max` parameter specifies the maximum limit to the amount of stack space that may be used in executing a process.
Value |  | Default: `rlimit_vmem_cur` * NBPP (0x20000000) Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a maximum restriction on stack space usage. The recommended initial value for large (64 processors or greater) systems is (0x20000000) ll.

### `rlimit_vmem_cur`

Description |  | The `rlimit_vmem_cur` parameter specifies the current limit to the amount of virtual memory that may be used in executing the process.
Value |  | Default: 0. If `rlimit_vmen_cur` is 0, it is automatically configured to the following: 0x7fffffffffffffff for Origin 3000, Origin 2000, Challenge, O200, and Onyx2 systems 0x80000000 for Indgio 2, Power Indgio 2, Octane, and O2 systems 0x40000000 for smaller systems Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a cap on virtual memory usage. The recommended initial value for large (64 processors or greater) systems is 0 ll.

### `rlimit_vmem_max`

Description |  | The `rlimit_vmem_max` parameter specifies the maximum limit to the amount of virtual memory that may be used in executing a process.
Value |  | Default: 0. If `rlimit_vmen_max` is 0, it is automatically configured to the following: 0x40000000 for smaller machines 0x80000000 for larger machines 0x7fffffffffffffff for the SN architecture Range: 0–0x7fffffffffffffff
When to change |  | Change this parameter when you want to place a maximum restriction on virtual memory usage or if your swap space is larger than the current parameter value. The recommended initial value for large (64 processors or greater) systems is 0 ll.

### `rsshogfrac`

Description |  | The `rsshogfrac` parameter specifies the percentage of memory allotted for resident pages. The number of physical memory pages occupied by a process at any given time is called its resident set size (RSS). The limit to the RSS of a process is determined by its allowable memory-use resource limit. `rsshogfrac` is designed to guarantee that even if one or more processes are exceeding their RSS limit, some percentage of memory is always kept free so that good interactive response is maintained. The percentage of total memory hogged is 100% minus `rsshogfrac` times maximum memory or 100 MB, whichever is less. Processes are permitted to exceed their RSS limit until either of the following occur: One or more processes exceed their default RSS limit (thereby becoming an RSS hog) and the amount of free memory drops below `rsshogfrac` of the total amount of physical memory. The amount of free memory drops below `gpgshi`. In either of these cases, the paging daemon runs and trims pages from all RSS processes exceeding the RSS limit. The parameter `rsshogfrac` is expressed as a fraction of the total physical memory of the system. The default value is 75%. This parameter is specified in `/var/sysgen/mtune`. For more information, see the `gpgshi`, `gpgslo`, and `rsshogslop` resource limits.
Value |  | Default: 75% of total memory Range: 0–100% of total memory
When to Change |  | The default value is adequate for most systems. The recommended initial value for large (64 processors or greater) systems is 99.

### `rsshogslop`

Description |  | The `rsshogslop` parameter specifies the number of pages above the resident set maximum that a process may use. To avoid thrashing (a condition where the computer devotes 100% of its CPU cycles to swapping and paging), a process can use up to `rsshogslop` more pages than its resident set maximum (see “ Resource Limits Parameters”). This parameter is specified in `/var/sysgen/mtune`. For more information, see the `rsshogfrac` resource limit.
Value |  | Default: 20
When to Change |  | The default value is adequate for most systems.

### `shlbmax`

Description |  | The `shlbmax` parameter specifies the maximum number of shared libraries with which a process can link. This parameter is specified in `/var/sysgen/mtune`.
Value |  | Default: 8 Range: 3–32
When to Change |  | The default value is adequate for most systems. Increase this parameter if you see the following message from `exec(2)`:
    ELIBMAX cannot link

### `cpulimit_gracetime`

Description |  | The `cpulimit_gracetime` parameter establishes a grace period for processes that exceed the cpu time limit. It is the number of seconds that a process is allowed to run after exceeding the limit set in the `rlimit_cpu_cur` parameter. When `cpulimit_gracetime` is not set (that is, it is zero), any process that exceeds either the process or job cpu limit is sent a `SIGXCPU` signal. The kernel continues to send `SIGXCPU` signals periodically as long as that process continues to execute. Since a process can register to handle `SIGXCPU`, the process can effectively ignore the CPU limit. If cpulimit_gracetime is set to a nonzero value via the `systune(1M)command`, the behavior changes. The kernel sends a `SIGXCPU` signal to a process one time when it exceeds the process cpu limit. The process can register for this signal and then perform any needed cleanup and shutdown operations. If the process is still running after accruing `cpulimit_gracetime` more seconds of cpu time, the kernel terminates the process with a `SIGKILL` signal.
Value |  | Default: 0 Range: 0-86400 (seconds) The recommended initial value is site dependent.

## Paging Parameters

The paging daemon, `vhand`, frees up memory as the need arises. This daemon uses a “least recently used” algorithm to approximate process working sets and writes those pages out to disks that have not been touched during a specified period of time. The page size is 4K for 32 bit kernels and 16K for 64 bit kernels.

The `vhand` program reclaims memory by:

- Stealing memory from processes that have exceeded their permissible resident set size maximum, forcing delayed write data buffers out to disk (with `bdflush`) so that the underlying pages can be reused

- Calling down to system resource allocators to trim back dynamically sized data structures

- Stealing pages from processes in order of lowest-priority process first, and the least-recently-used page first within that process

The following tunable parameters determine how often `vhand` runs and under what conditions. Note that the default values should be adequate for most applications.

The following parameters are included:

- `bdflushr` specifies how many buffers will be written to disk at a time; `bdflush` performs flushes of dirty filesystem buffers once per second.

- `gpgsmsk` specifies the mask used to determine if a given page may be swapped.

- `gpgshi` specifies the number of free pages above which `vhand` stops stealing pages.

- `gpgslo` specifies the number of free pages below which `vhand` starts stealing pages.

- `maxlkmem` specifies the maximum number of physical pages that can be locked in memory (by `mpin(2)` or `plock(2)`) by a non-superuser process.

- `maxfc` specifies the maximum number of pages that will be freed at once.

- `maxsc` specifies the maximum number of pages that may be swapped by the `vhand` daemon in a single operation.

- `maxdc` specifies the maximum number of pages that will be written to disk at once.

- `minarmem` specifies the minimum available resident pages of memory.

- `minasmem` specifies the minimum available swappable pages of memory.

- `numa_paging_node_freemem_low_threshold` specifies when to trigger a global system memory accounting procedure to check if `vhandfs` should be started.

- `scache_pool_size` specifies the amount of memory always kept in reserve for use by the paging daemon.

- `tlbdrop` specifies number of clock ticks before a process' wired entries are flushed.

- `vfs_syncr` specifies the rate at which `vfs_syncr` is run, in seconds.

- `maxpglst` specifies the maximum number of pages that can be held in each pageout queue.

- `zone_accum_limit` specifies the percentage of memory (in a node on a NUMA system) that can be accumulated before shaked is kicked off to shake the zone of free memory back into the global pool.

The following parameters determine page sizes as discussed in this section:

- `percent_totalmem_16k_pages`

- `percent_totalmem_64k_pages`

- `percent_totalmem_256k_pages`

- `percent_totalmem_1m_pages`

- `percent_totalmem_4m_pages`

- `percent_totalmem_16m_pages`

- `nlpages_64k`

- `nlpages_256k`

- `nlpages_1m`

- `nlpages_4m`

- `nlpages_16m`

### `bdflushr`

Description |  | The `bdflushr` parameter specifies how many buffers will be examined each time `bdflush` runs; `bdflush` performs periodic flushes of dirty filesystem buffers. It is parallel and similar to `vfs_syncr`. The `bdflush` daemon runs once per second. This parameter is specified in `/var/sysgen/mtune`. For more information, see the `autoup` kernel parameter.
Value |  | Default: 5 Range: 1–31536000
When to Change |  | The default value is adequate for most systems.

### `gpgsmsk`

Description |  | The `gpgsmsk` parameter specifies the mask used to determine if a given page may be swapped. Whenever the pager (`vhand`) is run, it decrements software reference bits for every active page. When a process subsequently references a page, the counter is reset to the limit (`NDREF`, as defined in `/usr/include/sys/immu.h`). When the pager is looking for pages to steal back (if memory is in short supply), it takes only pages whose reference counter has fallen to `gpgsmsk` or below. This parameter is specified in `/var/sysgen/mtune`. Also see `/usr/include/sys/immu.h` and `/usr/include/sys/tuneable.h` and the `gpgshi` and `gpgslo` kernel parameters for more information.
Value |  | Default: 2 Range: 0–7
When to Change |  | This value is adequate for most systems.
Notes |  | If the value is greater than 4, pages are written to the swap area earlier than they would be with the default value of `gpgsmsk`. Thus swapping/paging may occur before it should, unnecessarily using system resources.

### `gpgshi`

Description |  | When the `vhand` daemon (page handler) is stealing pages, it stops stealing when the amount of free pages is greater than `gpgshi`. In other words, `vhand` starts stealing pages when there are fewer than `gpgslo` free pages in the system. Once `vhand` starts stealing pages, it continues until there are `gpgshi` pages. If, at boot time, `gpgslo` and `gpgshi` are 0, the system sets `gpgshi` to 8% of the number of pages of memory in the system, and sets `gpgslo` to one half of `gpgshi`. This parameter is specified in `/var/sysgen/mtune`. For more information, see the kernel parameters `gpgsmsk` and `gpgslo`.
Value |  | Default: 0 (automatically configured to 8% of memory if set to 0) Range: 30 pages – 1/2 of memory
When to Change |  | This value is adequate for most systems. The recommended initial value for large (64 processors or greater) systems is 2000.
Notes |  | If this parameter is too small, `vhand` cannot supply enough free memory for system-wide demand. ``

### `gpgslo`

Description |  | When the `vhand` daemon (page handler) executes, it would not start stealing back pages unless there are fewer than `gpgslo` free pages in the system. Once `vhand` starts stealing pages, it continues until there are `gpgshi` pages. This parameter is specified in `/var/sysgen/mtune`. For more information, see the `gpgshi` and `gpgsmsk` kernel parameters.
Value |  | Default: 0 (automatically configured to half of `gpgshi` if set to 0) Range: 10 pages – 1/2 of memory
When to Change |  | This value is adequate for most systems. The recommended initial value for large (64 processors or greater) systems is 1000.
Notes |  | If this parameter is too small, `vhand` does not start swapping pages; thus entire processes must be swapped. If this parameter is too large, `vhand` swaps pages unnecessarily.

### `maxlkmem`

Description |  | The `maxlkmem` parameter specifies the maximum number of physical pages that can be locked in memory (by `mpin(2)` or `plock(2)`) per non-superuser process. This parameter is specified in `/var/sysgen/mtune`.
Value |  | Default: 2000 Range: 0 pages – 3/4 of physical memory
When to Change |  | Increase this parameter only if a particular application has a real need to lock more pages in memory. On multi-user servers, you may want to decrease this parameter and also decrease `rlimit_vmem_cur`.
Notes |  | When pages are locked in memory, the system cannot reclaim those pages, and therefore cannot maintain the most efficient paging.

### `maxfc`

Description |  | The `maxfc` parameter specifies the maximum number of pages that may be freed by the `vhand` daemon in a single operation. When the paging daemon (`vhand`) starts stealing pages, it collects pages that can be freed to the general page pool. It collects, at most, `maxfc` pages at a time before freeing them. Do not confuse this parameter with `gpgshi`, which sets the total number of pages that must be free before `vhand` stops stealing pages. This parameter is specified in `/var/sysgen/mtune`.
Value |  | Default: 100 Range: 50–100
When to Change |  | This value is adequate for most systems.

### `maxsc`

Description |  | The `maxsc` parameter specifies the maximum number of pages that may be swapped by the `vhand` daemon in a single operation. When the paging daemon starts tossing pages, it collects pages that must be written out to swap space before they are actually swapped and then freed into the general page pool. It collects at most `maxsc` pages at a time before swapping them out. This parameter is specified in `/var/sysgen/mtune`.
Value |  | Default: 100 Range: 8–100
When to Change |  | You may want to decrease this parameter on systems that are swapping over NFS ( Network File System). This is always the case for diskless systems to increase performance.

### `maxdc`

Description |  | The `maxdc` parameter is the maximum number of pages which can be saved up and written to the disk at one time.
Value |  | Default: 100 pages Range: 1-100
When to Change |  | If the system is low on memory and consistently paging out user memory to remote swap space (for example, mounted via NFS), decrease this parameter by not more than ten pages at a time. However, this parameter's setting does not usually make any measurable difference in system performance.

### `minarmem`

Description |  | The `minarmem` parameter represents the minimum available resident memory that must be maintained in order to avoid deadlock.
Value |  | Default: 0 (Autoconfigured if set to 0)
When to Change |  | The automatically configured value of this parameter should always be correct for each system. You should not have to change this parameter.

### `minasmem`

Description |  | The `minasmem` parameter represents the minimum available swappable memory that must be maintained in order to avoid deadlock.
Value |  | Default: 0 (Autoconfigured if set to 0)
When to Change |  | The automatically configured value of this parameter should always be correct for each system. You should not have to change this parameter.

### `numa_paging_node_freemem_low_threshold`

Description |  | The `numa_paging_node_freemem_low_threshold` parameter specifies when to trigger a global system memory accounting procedure to check if `vhand` should be started.
Value |  | Default: 40

### `scache_pool_size`

Description |  | The `scache_pool_size` parameter specifies the amount of memory always kept in reserve for use by the paging daemon. The value is the number of kilobytes reserved, which is always rounded up to the next page boundary.
Value |  | Default: 32
When to Change |  | Use caution when changing this parameter. Setting it too low will result in memory deadlocks. Setting it too high will waste memory. If the system panics with the message`scache... out of memory,` then this parameter should be increased. Otherwise, you should not have to change this parameter.

### `tlbdrop`

Description |  | The `tlbdrop` parameter specifies the number of clock ticks before a process's wired entries are flushed.
Value |  | Default: 100
When to Change |  | If `sar` indicates a great deal of transaction lookaside buffer (`utlbmiss`) overhead in a very large application, you may need to increase this parameter. In general, the more the application changes the memory frame of reference in which it is executing, the more likely increasing `tlbdrop` will help performance. You may have to experiment somewhat to find the optimum value for your specific application.

### `vfs_syncr`

Description |  | The `vfs_syncr` parameter specifies the number of seconds between runs of the `vfs_syncr` process.
Value |  | Default: 30 Range: 1 - 31536000 (1 year)
When to Change |  | Under normal circumstances it is not necessary to change this parameter.

### `maxpglst`

Description |  | The `maxpglst` parameter specifies the maximum number of pages that can be held in each of the pager's pageout queues.
Value |  | Default: 0 (Autoconfigured) Range: 50 - 1000

### `zone_accum_limit`

Description |  | The `zone_accum_limit` parameter specifies the percentage of memory (in a node on a NUMA system) that can be accumulated before shaked is kicked off to shake the zone of free memory back into the global pool. This parameter is set to 30%, which means if the amount of free memory kept in zones exceeds 30%, shaked is kicked off.
Value |  | Default: 30 Range: 0 - 100

### `percent_totalmem_64k_pages`

Description |  | The `percent_totalmem_64k_pages` parameter specifies the percentage of total memory that can be used as an upper limit for the number of 64 KB pages.
Value |  | Default: 0 Range: 0-100 (%)
When to Change |  | Set dynamically to get 64 KB pages. The recommended initial value for large (64 processors or greater) systems is 0.
| Note: Other possible values are discussed in “Multiple Page Sizes” in Chapter 10.

### `nlpages_64k`

Description |  | The `nlpages_64k` parameter is used to reserve 64 KB pages at boot time. This increases the probability of getting large pages in a low memory system.
Value |  | Default: 0 Range: 0-memory_size/64*1024, where memory_size is the total amount of memory in the system.
When to Change |  | Not recommended unless absolutely necessary.
| Note: Other possible values are discussed in “Multiple Page Sizes” in Chapter 10.

## IPC Parameters

The IPC tunable parameters set interprocess communication (IPC) structures. These structures include IPC messages, specified in `/var/sysgen/mtune/msg`; IPC semaphores, specified in `/var/sysgen/mtune/sem`; and IPC shared memory, specified in `/var/sysgen/mtune/kernel`.

If IPC (interprocess communication) structures are incorrectly set, certain system calls will fail and return errors.

Before increasing the size of an IPC parameter, investigate the problem by using `ipcs(1)` to see if the IPC resources are being removed when no longer needed. For example, `shmget` returns the error `ENOSPC` if applications do not remove semaphores, memory segments, or message queues.

Note that IPC objects differ from most IRIX objects in that they are not automatically freed when all active references to them are gone. In particular, they are not deallocated when the program that created them exits.

Table A-1 lists error messages, system calls that cause the error, and parameters to adjust. Subsequent paragraphs explain the details you need to know before you increase the parameters listed in this table.

Table A-1. System Call Errors and IPC Parameters to Adjust

Message | System Call | Parameter
--- | --- | ---
`EAGAIN` | `msgsnd()` | see below
`EINVAL` | `msgsnd() shmget()` | `msgmax shmmax`
`EMFILE` | `shmat()` | `sshmseg`
`ENOSPC` | `semget() shmget()` | `msgmni semmni shmmni`

`EAGAIN` |  | If `IPC_NOWAIT` is set, `msgsnd` can return `EAGAIN` for a number of reasons: The total number of bytes on the message queue exceeds `msgmnb`. The total number of bytes used by messages in the system exceeds `msgseg``*` `msgssz`. The total number of system-wide message headers exceeds `msgtql`.
`EINVAL` |  | `shmget` (which gets a new shared memory segment identifier) will fail with `EINVAL` if the given size is not within `` `shmmin` and `shmmax`. Since `shmmin` is set to the lowest possible value (1), and `shmmax` is very large, it should not be necessary to change these values.
`EMFILE` |  | `shmat` will return `EMFILE` if it attaches more than `sshmseg` shared memory segments. `sshmseg` is the total number of system-shared memory segments per process.
`ENOSPC` |  | `shmget` will return `ENOSPC` if `shmmni` (the system-wide number of shared memory segments) is too small. However, applications may be creating shared memory segments and forgetting to remove them. So, before making a parameter change, use `ipcs(1)` to get a listing of currently active shared memory segments. `semge` `t` returns `ENOSPC` if `semmni` is too small, indicating that the total number of semaphore identifiers is exceeded. `msgget` will return `ENOSPC` if `msgmni` is too small. Use `ipcs` to see if message queues are being removed as they should be.

## IPC Messages Parameters

If no one on the system uses or plans to use IPC messages, you may want to consider excluding this module. The following tunable parameters are associated with interprocess communication messages (see the `msgctl(2)` man page):

- `msgmax` specifies the maximum size of a message.

- `msgmnb` specifies the maximum length of a message queue.

- `msgmni` specifies the maximum number of message queues system-wide.

- `msgseg` specifies the maximum number of message segments system-wide.

- `msgssz` specifies the size, in bytes, of a message segment.

- `msgtql` specifies the maximum number of message headers system-wide.

### `msgmax`

Description |  | The `msgmax` parameter specifies the maximum size of a message. This parameter is specified in `/var/sysgen/mtune/msg`.
Value |  | Default: 16 * 1024 (0x4000) Range: 512-0x8000
When to Change |  | Increase this parameter if the maximum size of a message needs to be larger. Decrease the value to limit the size of messages.

### `msgmnb`

Description |  | The `msgmnb` parameter specifies the maximum length of a message queue. This parameter is specified in `/var/sysgen/mtune/msg`.
Value |  | Default: 32 * 1024 (0x8000) Range: `msgmax`–1/2 of physical memory
When to Change |  | Increase this parameter if the maximum number of bytes on a message queue needs to be longer. Decrease the value to limit the number of bytes per message queue.

### `msgmni`

Description |  | The `msgmni` parameter specifies the maximum number of message queues system-wide. This parameter is specified in `/var/sysgen/mtune/msg`.
Value |  | Default: 50 Range: 10–1000
When to Change |  | Increase this parameter if you want more message queues on the system. Decrease the value to limit the message queues.
Notes |  | If there are not enough message queues, a`msgget(2)` system call that attempts to create a new message queue returns the error:
    ENOSPC: No space left on device

### `msgseg`

Description |  | The `msgseg` parameter specifies the maximum number of message segments system-wide. A message on a message queue consists of one or more of these segments. The size of each segment is set by the `msgssz` parameter. This parameter is specified in `/var/sysgen/mtune/msg`.
Value |  | Default: 1536
When to Change |  | Modify this parameter to reserve the appropriate amount of memory for messages. Increase this parameter if you need more memory for message segments on the system. Decrease the value to limit the amount of memory used for message segments.
Notes |  | If this parameter is too large, memory may be wasted (saved for messages but never used). If this parameter is too small, some messages that are sent will not fit into the reserved message buffer space. In this case, a `msgsnd(2)` system call waits until space becomes available.

### `msgssz`

Description |  | The `msgssz` parameter specifies the size, in bytes, of a message segment. Messages consist of a contiguous set of message segments large enough to accommodate the text of the message. Using segments helps to eliminate fragmentation and speed the allocation of the message buffers. This parameter is specified in `/var/sysgen/mtune/msg`.
Value |  | Default: 8
When to Change |  | This parameter is set to minimize wasted message buffer space. Change this parameter only if most messages do not fit into one segment with a minimum of wasted space. If you modify this parameter, you may also need to change the `msgseg` parameter.
Notes |  | If this parameter is too large, message buffer space may be wasted by fragmentation, which in turn may cause processes that are sending messages to sleep while waiting for message buffer space.

### `msgtql`

Description |  | The `msgtql` parameter specifies the maximum number of message headers system-wide, and thus the number of outstanding (unread) messages. One header is required for each outstanding message. This parameter is specified in `/var/sysgen/mtune/msg`.
Value |  | Default: 40 Range: 10–4000
When to Change |  | Increase this parameter if you require more outstanding messages. Decrease the value to limit the number of outstanding messages.
Notes |  | If this parameter is too small, a `msgsnd(2)` system call attempting to send a message that would put `msgtql` over the limit waits until messages are received (read) from the queues.

## IPC Semaphores Parameters

If no one on the system uses or plans to use IPC semaphores, you may want to consider excluding this module.

The following tunable parameters are associated with interprocess communication semaphores (see the `semctl(2)` man page):

- `semmni` specifies the maximum number of semaphore identifiers in the kernel.

- `semmsl` specifies the maximum number of semaphores per semaphore identifier.

- `semopm` specifies the maximum number of semaphore operations that can be executed per `semop(2)` system call.

- `semvmx` specifies the maximum value that a semaphore can have.

- `semaem` specifies the adjustment on exit for maximum value.

### `semmni`

Description |  | The `semmni` parameter specifies the maximum number of semaphore identifiers in the kernel. This is the number of unique semaphore sets that can be active at any given time. Semaphores are created in sets; there may be more than one semaphore per set. This parameter is specified in `/var/sysgen/mtune/sem`.
Value |  | Default: 300
When to Change |  | Increase this parameter if processes require more semaphore sets. Increasing this parameter to a large value requires more memory to keep track of semaphore sets. If you modify this parameter, you may need to modify other related parameters. The recommended initial value for large (64 processors or greater) systems is 2000.

### `semmsl`

Description |  | The`semmsl` parameter specifies the maximum number of semaphores per semaphore identifier. This parameter is specified in `/var/sysgen/mtune/sem`.
Value |  | Default: 100
When to Change |  | Increase this parameter if processes require more semaphores per semaphore identifier.

### `semopm`

Description |  | The`semopm` parameter specifies the maximum number of semaphore operations that can be executed per `semop()` system call. This parameter permits the system to check or modify the value of more than one semaphore in a set with each `semop()` system call. This parameter is specified in `/var/sysgen/mtune/sem`.
Value |  | Default: 100
When to Change |  | Change this parameter to increase/decrease the number of operations permitted per `semop()` system call. You may need to increase this parameter if you increase `semmsl` (the number of semaphore sets), so that a process can check/modify all the semaphores in a set with one system call.

### `semvmx`

Description |  | The `semvmx` parameter specifies the maximum value that a semaphore can have. This parameter is specified in `/var/sysgen/mtune/sem`.
Value |  | Default: 32767 (maximum value)
When to Change |  | Decrease this parameter if you want to limit the maximum value for a semaphore.

### `semaem`

Description |  | The `semaem` parameter specifies the adjustment on exit for maximum value, alias `semadj`. This value is used when a semaphore value becomes greater than or equal to the absolute value of semop(2), unless the program has set its own value. This parameter is specified in `/var/sysgen/mtune/sem`.
Value |  | Default: 16384 (maximum value)
When to Change |  | Change this parameter to decrease the maximum value for the adjustment on exit value.

## IPC Shared Memory Parameters

The following tunable parameters are associated with interprocess communication shared memory:

- `shmmax` specifies the maximum size in bytes of an individual shared memory segment.

- `shmmin` specifies the minimum size in bytes of an shared memory segment.

- `shmmni` specifies the maximum number of shared memory identifiers system-wide.

- `sshmseg` specifies the maximum number of attached shared memory segments per process.

### `shmmax`

Description |  | The `shmmax` parameter specifies the maximum size in bytes of an individual shared memory segment. This parameter is specified in `/var/sysgen/mtune/kernel`.
Value |  | Default: 0 32-bit Range: 0x1000 - 0x7fffffff 64-bit Range: 0x1000 - 0x7fffffffffffffff ll
When to Change |  | If the value of `shmmax` is 0, it will be adjusted to be 80% of the system memory size at boot time. If the default value specifies a number, kernel will obey that. Keep this parameter small if it is necessary that a single shared memory segment not use too much memory. The recommended initial value for large (64 processors or greater) systems is (0x4000000) 11.

### `shmmin`

Description |  | The `shmmin` parameter specifies the minimum size in bytes of a shared memory segment. This parameter is specified in `/var/sysgen/mtune/kernel`.
Value |  | Default: 1 byte Range: 1
When to Change |  | Increase this parameter if you want an error message to be generated when a process requests a shared memory segment that is too small.

### `shmmni`

Description |  | The`shmmni` parameter specifies the maximum number of shared memory segments system-wide. This parameter is specified in `/var/sysgen/mtune/kernel`.
Value |  | Default: 0 Range: 5–100000
When to Change |  | If shmmni default value is 0, it will be adjusted at boot time to be the same value as the `nproc` tunable variable. If the default value specifies a number, kernel will obey that. Increase this parameter by one (1) for each additional shared memory segment that is required, and also if processes that use many shared memory segments reach the `shmmni` limit. Decrease this parameter if you need to reduce the maximum number of shared memory segments of the system at any one time. Also decrease it to reduce the amount of kernel space taken for shared memory segments.

### `sshmseg`

Description |  | The`sshmseg` parameter specifies the maximum number of attached shared memory segments per process. A process must attach a shared memory segment before the data can be accessed. This parameter is specified in `/var/sysgen/mtune/kernel`.
Value |  | Default: 2000 Range: 1–10000
When to Change |  | Increase this parameter if processes need to attach more than the default number of shared memory segments at one time.

## Streams Parameters

The following parameters are associated with streams processing:

- `nstrpush` specifies the maximum number of modules that can be pushed on a stream.

- `nstrintr` specifies the maximum number.

- `strctlsz` specifies the maximum size of the ctl part of message.

- `strmsgsz` specifies the maximum stream message size.

- `strholdtime` specifies the maximum stream hold time.

- `strpmonmax` specifies the maximum private monitors.

### `nstrpush`

Description |  | The `nstrpush` parameter defines the maximum number of streams modules that can be pushed on a single stream.
Value |  | Default: 9 (0x9) Range: 9-10
When to Change |  | Change `nstrpush` from 9 to 10 modules when you need an extra module.

### `nstrintr`

Description |  | The `nstrintr` parameter defines the streams buffers used at interrupt time.
Value |  | Default: 1024 (0x400) Range: 32-4096

### `strctlsz`

Description |  | The `strctlsz` parameter is the maximum size of the ctl buffer of a streams message. See the `getmsg(2)` or `putmsg(2)` man pages for a discussion of the ctl and data parts of a streams message.
Value |  | Default: 1024 (0x400)
When to Change |  | Change `strctlsz` when you need a larger buffer for the ctl portion of a streams message.

### `strmsgsz`

Description |  | The `strmsgsz` parameter defines the maximum streams message size. This is the maximum allowable size of the ctl part plus the data part of a message. Use this parameter in conjunction with the `strctlsz` parameter described above to set the size of the data buffer of a streams message. See the `getmsg(2)` or `putmsg(2)` man pages for a discussion of the ctl and data parts of a streams message.
Value |  | Default: 0x8000
When to Change |  | Change this parameter in conjunction with the `strctlsz` parameter to adjust the sizes of the streams message as a whole and the data portion of the message.

### `strholdtime`

Description |  | The `strholdtime` parameter defines the `STRHOLDTIME` macro in <`strsubr.h`>. The purpose of this macro is to cut down on overhead on streams drivers. This happens at a cost to system latency.
Value |  | Default: 50 (0x32) Range: 0-1000

### `strpmonmax`

Description |  | The `strpmonmax` parameter defines the maximum number of private streams monitors
Value |  | Default: 4 (0x4) Range: 0-1024

## Signal Parameter

The `maxsigq` signal parameter controls the operation of interprocess signals within the kernel: it specifies the maximum number of signals that can be queued.

### `maxsigq`

Description |  | The `maxsigq` parameter specifies maximum number of signals that can be queued. Normally, multiple instances of the same signal result in only one signal being delivered. With the use of the `SA_SIGINFO` flag, outstanding signals of the same type are queued instead of being dropped.
Value |  | Default: 64 Range: 32-32767
When to Change |  | Raise `maxsigq` when a process expects to receive a great number of signals and 64 queue places may be insufficient to avoid losing signals before they can be processed. Change `maxsigq` to a value appropriate to your needs.

## Dispatch Parameters

One of the most important functions of the kernel is dispatching processes. When a user issues a command and a process is created, the kernel endows the process with certain characteristics. For example, the kernel gives the process a priority for receiving CPU time. This priority can be changed by the user who requested the process or by the Superuser. Also, the length of time (`slice-size`) that a process receives in the CPU is adjustable by a dispatch parameter. The Periodic Deadline Scheduler (PDS) is also part of the dispatch group. The deadline scheduler is invoked via the `schedctl(2)` system call in a user program and requires the inclusion of the `sys/schedctl.h` file. The following parameters are included in the dispatch group:

- `memaff_sched` turns the scheduler's memory affinity preference on or off.

- `slice_size` specifies the amount of time a process receives at the CPU.

### `memaff_sched`

Description |  | The `memaff_sched` parameter turns the scheduler's memory affinity preference on or off.
Value |  | Default: 1 Range: 0-1
When to Change |  | Change this parameter when you want to turn the scheduler's memory affinity preference on or off.

### `slice_size`

Description |  | The `slice_size` parameter is the default process time slice, expressed as a number of ticks of the system clock. The frequency of the system clock is expressed by the constant Hz, which has a value of 100. Thus each unit of `slice_size` corresponds to 10 milliseconds. When a process is given control of the CPU, the kernel lets it run for `slice_size` ticks. When the time slice expires or when the process voluntarily gives up the CPU (for example, by calling `pause(2)` or by doing some other system call that causes the process to wait), the kernel examines the run queue and selects the process with the highest priority that is eligible to run on that CPU. The `slice_size` parameter is defined in `/var/sysgen/mtune/disp` and has the following formula:
    #define slice_size Hz / 30 int slice_size = slice_size
Value |  | Default: 2 for single CPU systems, 10 for multiprocessor systems Range: 1–100
When to Change |  | If you use the system primarily for compute-intensive jobs and interactive response is not an important consideration, you can increase `slice_size`. For example, setting `slice_size` to 10 gives greater efficiency to the compute jobs, since each time they get control of the CPU, they are able to run for 100 milliseconds before getting switched out. In situations where the system runs both compute jobs and interactive jobs, interactive response time will suffer as you increase the value of `slice_size`.

### `rtcpus`

Description |  | The `rtcpus` parameter controls the quality of the real-time scheduler. If this option is turned on, it enables the IRIX operating system to guarantee a one millisecond response time. Turning it on, especially on large systems, reduces system performance. It is expressed in the number of processors and is turned on if it is greater or equal to the number of processors in the system.
Value |  | Default: 0 (Off) Range: 0 - 512
When to Change |  | For most machines, the default is sufficient. If the guaranteed response time is required, it should be turned on.

## Filesystem Parameters

IRIX filesystems work closely with the operating system kernel, and the following parameters adjust the kernel's interface with the filesystem.

The following parameter is defined in the `efs` group:`efs_inline` specifies whether to store symbolic link information in the inode or not.

The following parameters are set in the `kernel` parameter group, and are used for both EFS and XFS filesystem tuning. They determine how many pages of memory are clustered together into a single disk write operation. Adjusting these parameters can greatly increase filesystem performance. Available parameters include:

- `cwcluster` specifies number of commit write pages to cluster in each push.

- `bdflush_interval` specifies the interval at which the `bdflush` function executes to push dirty file data to disk.

- `dwcluster` specifies number of delayed-write pages to cluster in each push.

- `min_file_pages` specifies the minimum number of file pages to keep in the cache when the memory gets low.

- `min_free_pages` specifies the minimum number of free pages when the number of file pages is above `min_file_pages`.

- `autoup` specifies the age, in seconds, that a buffer marked for delayed write must be before the `bdflush` daemon writes it to disk.

### `efs_inline`

Description |  | If the `efs_inline` parameter is set to any value other than 0, any symbolic link data is stored within a file's inode, rather than out-of-line.
Value |  | Default: 0 Range: 0-1
When to Change |  | It should not be necessary to change this variable. Increasing the value improves the lookup speed of symbolic links to some degree; however filesystems thus treated cannot be transferred to systems running releases of the IRIX system prior to version 5.3.

### `bdflush_interval`

Description |  | The `bdflush_interval` parameter specifies the interval at which the bdflush function executes to push dirty file data to disk. It is expressed in 10 microsecond intervals.
Value |  | Default: 100 (Once per second)
When to Change |  | For most machines, the default is sufficient

### `cwcluster`

Description |  | The `cwcluster` parameter sets the maximum number of commit write pages to cluster in each push. This parameters applies to NFS I/O only.
Value |  | Default: 64
When to Change |  | It should not be necessary to change this parameter. The automatically configured value is sufficient.

### `dwcluster`

Description |  | The `dwcluster` parameter sets the maximum number of delayed-write pages to cluster in each push. This amount cannot be greater than the value of `maxdmasz`.
Value |  | Default: 64
When to Change |  | It should not be necessary to change this parameter. The automatically configured value is sufficient.

### `min_file_pages`

Description |  | The `min_file_pages` parameter sets the minimum number of file pages to keep in the cache when memory gets low. It is autoconfigured to 3% of the system's memory if it is 0. When setting this parameter, remember that the page size is 4K in 32-bit kernels and 16K in 64-bit kernels.
Value |  | Default: 0
When to Change |  | It should not be necessary to change this parameter. The automatically configured value is sufficient.

### `min_free_pages`

Description |  | The `min_free_pages` parameter sets the minimum number of free pages when the number of file pages is above `min_file_pages`. The default value is `gpgshi`*2 for systems with less than 600M of memory. For larger memory systems, the default value is `gpgshi`*4.
Value |  | Default: 0

### `autoup`

Description |  | The `autoup` parameter specifies the age, in seconds, that a buffer marked for delayed write must be before the `bdflush` daemon writes it to disk. This parameter is specified in `/var/sysgen/mtune`. For more information, see the entry for the `bdflushr` kernel parameter. The `autoup` parameter is also used to determine the age of clean data that is marked inactive and shows up in the `gr_osview rmemc` command's `freec` label. The value is computed with the following algorithm: `autoup`*HZ/2, or a default of 10*100/2 = 500 seconds.
Value |  | Default: 10 Range: 1–30
When to Change |  | This value is adequate for most systems.

## Loadable Drivers Parameters

The IRIX operating system allows you to load and run device drivers while the system remains up and running. Occasionally, you may have to make adjustments to the running kernel to allow for the extra resources these loadable drivers require. The following parameters allow you to make the necessary adjustments:

- `bdevsw_extra` specifies an extra number of entries in the block device switch.

- `cdevsw_extra` specifies an extra number of entries in the character device switch.

- `fmodsw_extra` specifies an extra number of entries in the streams module switch.

- `vfssw_extra` specifies an extra number of entries in the virtual filesystem module switch.

- `munlddelay` specifies the timeout for auto-unloading loadable modules.

### `bdevsw_extra`

Description |  | The `bdevsw_extra` parameter specifies an extra number of entries in the block device switch. This parameter is for use by loadable drivers only. If you configured a block device into the system at `lboot(1M)` time, you will not need to add extra entries to `bdevsw`.
Value |  | Default: 21 Range: 1-254
When to Change |  | Change this parameter when you have more than 21 block devices to load into dynamically the system. The IRIX system provides 21 spaces in the `bdevsw` by default.

### `cdevsw_extra`

Description |  | The `cdevsw_extra` parameter specifies an extra number of entries in the character device switch. This parameter is for use by loadable drivers only. If you configured a character device into the system at `lboot(1M)` time, you will not need to add extra entries to `cdevsw`.
Value |  | Default: 23 Range: 3-254
When to Change |  | Change this parameter when you have more than 23 character devices to load dynamically into the system. The IRIX system provides 23 spaces in the `cdevsw` by default.

### `fmodsw_extra`

Description |  | The `fmodsw_extra` parameter specifies an extra number of entries in the streams module switch. This parameter is for use by loadable drivers only. If you configured a streams module into the system at `lboot(1M)` time, you will not need to add extra entries to `fmodsw`.
Value |  | Default: 20 Range: 0-254
When to Change |  | Change this parameter when you have more than 20 streams modules to load dynamically into the system. The IRIX system provides 20 spaces in the `fmodsw` by default.

### `vfssw_extra`

Description |  | The `vfssw_extra` parameter specifies an extra number of entries in the `vnode` filesystem module switch. This parameter is for use by loadable drivers only. If you configured a `vfs` module into the system at `lboot` time, you will not need to add extra entries to `vfssw`.
Value |  | Default: 5 Range: 0-254
When to Change |  | Change this parameter when you have more than five virtual filesystem modules to load dynamically into the system. The IRIX system provides five spaces in the `vfssw` by default.

### `munlddelay`

Description |  | The `munlddelay` parameter specifies the timeout in minutes after which to auto-unload loadable modules.
Value |  | Default: 5 (0x5) minutes

## CPU Action Parameter

CPU action parameter was used in multiprocessor systems to allow the user to select the processor or processors that will be used to perform a given task. The `nactions` parameter controlled the number of action blocks. The kernel now allocates the `naction` blocks dynamically when needed. The `nactions` parameter still exists in the `/var/sysgen/mtune` files to preserve compatibility, but it no longer has any effect.

## Switch Parameters

The following parameters are simple on/off switches within the kernel that allow or disallow certain features, such as whether shells that set the user ID to the superuser are allowed:

- `panic_on_sbe` controls special factory debugging mode.

- `sbe_log_errors` controls system logging of single bit errors.

- `sbe_mfr_override` overrides default action of disabling single bit errors.

- `sbe_report_cons` controls single bit error console reporting.

- `corepluspid` controls core filenames.

- `r4k_div_patch` controls patch code for `r4kpp` binaries.

- `mload_auto_rtsyms` controls loading of the kernel symbol table.

- `xpg4_sticky_dir` controls removal of files in sticky directories.

- `tty_auto_strhold` controls the setting of `STRHOLD` on tty/pty lines.

- `reset_limits_on_exec` controls resetting of rlimit values on new setuid processes.

- `ip26_allow_ucmem` controls whether to allow access to uncached system memory on POWER Indigo2 systems.

- `restrict_fastprof` controls whether users can do fast (1ms) user level profiling.

- `reboot_on_panic` specifies that the system should automatically reboot after a kernel panic.

- `svr3pipe` controls whether SVR3.2 or SVR4 pipes are used.

- `nosuidshells` allows applications to create superuser-privileged shells when the parameter is set to 0. When set to any value other than 0, such shells are not permitted.

- `posix_tty_default` specifies whether the default SGI line disciplines are used. If the value of this switch is 0, the default SGI line disciplines are used. If the value is set to 1, POSIX line disciplines and settings are used.

- `restricted_chown` allows you to decide whether you want to use BSD UNIX style `chown(2)` system call or the System V style.

- `use_old_serialnum` forces the kernel to use the old method of calculating a 32-bit serial number for `sysinfo -s` when the parameter is set to 1. This variable affects only Onyx and Challenge L or XL systems.

- `subnetsarelocal` specifies whether other subnets of a directly-connected subnetted network are considered to be local when the parameter is set to 1.

- `process_core_cpu_logging` controls a special factory debugging mode that enables logging of the CPU on which an exception occurs causing a process to core dump.

Note that all the above listed parameters are enforced system-wide. It is not possible to select different values on a per-process basis.

### `panic_on_sbe`

Description |  | The `panic_on_sbe` parameter, when set to 1, turns on a special factory debugging mode called single bit errors. When set to 0, this feature is disabled.
Value |  | Default: 0 (0x0) Range: 0 or 1

### `sbe_log_errors`

Description |  | The `sbe_log_errors` parameter, when set to 1, directs the system to log single bit errors to the `SYSLOG`. When set to 0, this feature is disabled.
Value |  | Default: 0 (0x0) Range: 0 or 1
Notes |  | This parameter applies only to systems containing ECC memory (R8000-based systems such as Challenge and Onyx systems).

### `sbe_mfr_override`

Description |  | The `sbe_mfr_override` parameter, when set to 1, overrides the default action of disabling single bit errors if the rate of single bit errors exceeds a predetermined limit. When set to 0, this feature is disabled.
Value |  | Default: 0 (0x0) Range: 0 or 1
Notes |  | This parameter applies only to systems containing ECC memory (R8000-based systems such as Challenge and Onyx systems).

### `sbe_report_cons`

Description |  | The `sbe_report_cons` parameter, when set to 1, directs the system to display single bit errors on the system console. When set to 0, this feature is disabled.
Value |  | Default: 0 (0x0) Range: 0 or 1
Notes |  | This parameter applies only to systems containing ECC memory (R8000-based systems such as Challenge and Onyx systems).

### `corepluspid`

Description |  | The `corepluspid` parameter, when set to 1, directs the system to name core files with the process ID number appended. When set to 0, this feature is disabled.
Value |  | Default: 0 (0x0) Range: 0 or 1

### `r4k_div_patch`

Description |  | The `r4k_div_patch` parameter, when set to 1, enables the exec patch code for binaries that have been processed with r4kpp for the divide in branch delay slot problem that occurs on R4000 SC rev 2.2 and 3.0 parts. When set to 0, this feature is disabled.
Value |  | Default: 0 (0x0) Range: 0 or 1

### `mload_auto_rtsyms`

Description |  | The `mload_auto_rtsyms` parameter, when set to 1, enables the standard automatic loading of the kernel's run-time symbol table. When set to 0, this feature is disabled.
Value |  | Default: 1 (0x1) Range: 0 or 1

### `xpg4_sticky_dir`

Description |  | The `xpg4_sticky_dir` parameter, when set to 1, specifies that write access to a file does not allow that file to be removed if the sticky bit is set in the directory in which it resides. When set to 0, such files can be removed.
Value |  | Default: 1 (0x1) Range: 0 or 1

### `tty_auto_strhold`

Description |  | The `tty_auto_strhold` parameter, when set to 1, automatically sets `STRHOLD` on ttys/ptys whenever the line discipline is in canonical & echo mode and automatically clears `STRHOLD` otherwise. When set to 0, this feature is under user control.
Value |  | Default: 0 (0x0) Range: 0 or 1

### `reset_limits_on_exec`

Description |  | The `reset_limits_on_exec` parameter, when set to 1, directs the kernel to reset rlimit values on processes that run as `root`, in order to prevent non-`root` processes from enforcing resource limits. When set to 0, this feature is disabled and resource limits are not reset. Modifying this parameter may have security implications.
Value |  | Default: 1 (0x1) Range: 0 or 1

### `ip26_allow_ucmem`

Description |  | The `ip26_allow_ucmem` parameter, when set to 0, prevents users from accessing uncached system memory on IP26 (POWER Indigo2) systems. When set to 1, this feature is allowed.
Value |  | Default: 0 (0x0) Range: 0 or 1
When to Change |  | If this parameter is set to 0, attempts to access uncached memory will cause a system panic. If the feature is allowed, there is a substantial memory performance degradation.

### `restrict_fastprof`

Description |  | The `restrict_fastprof` parameter, when set to 0, allows users to do fast (1 ms) profiling of programs with `prof`. When set to 1, this feature is disallowed.
Value |  | Default: 0 (0x0) Range: 0 or 1

### `reboot_on_panic`

Description |  | The `reboot_on_panic` parameter, when set to 1, specifies that the system should automatically reboot after a kernel panic. This is especially useful for servers or other systems that frequently go unattended or are used remotely, where the user may not conveniently be able to physically reset and reboot the system. When set to 0, the system must be rebooted from the console. Systems with IP19, IP20, IP21, IP22, IP25, IP26, IP27, IP28, IP30, IP32 and IP35 processors (check your `hinv` listing for your processor type) store an environment variable in the PROM monitor called rebound. If you have the rebound variable and set the `reboot_on_panic` parameter to -1, your system will check the PROM environment for instructions. For desktop systems (IP20, IP22, IP26, IP28, IP30, IP32), if the rebound variable is set to y, then the system will reboot automatically. If the rebound variable is set to n, the system will require manual reset. For the other platforms, IP19, IP21, IP25, IP27, IP35, if the rebound variable is not set to y (IP19, IP21, IP25) and the `reboot_on_panic` parameter is -1, the default, then the system behaves as though the setting is 1. If you do not have the rebound variable and set the `reboot_on_panic` parameter to -1, your system behaves as though the setting is 0 and does not automatically reboot. It is important to note that the rebound variable is always checked before the `reboot_on_panic` parameter and can override it. If the `reboot_on_panic` parameter is set to 0 and the rebound value is set to y, the `reboot_on_panic` parameter in effect becomes 1 and your system will automatically reboot.
| Note: The default for SGI servers and large graphical systems is to reboot after a kernel panic.
Value |  | Default: -1 (automatically reboot according to hardware platform implementation) or 0, depending on processor type. A value of 1 also automatically reboots a system. Range: -1, 0, or 1
When to Change |  | Change this parameter if you wish to automatically reboot after a system panic.

### `svr3pipe`

Description |  | The `svr3pipe` parameter specifies whether the default SGI line disciplines are used. I parameter, when set to 1, specifies SVR3.2 style pipes, which are unidirectional. When set to 0, SVR4 style pipes are specified, which are bidirectional.
Value |  | Default: 1 (SVR3.2 style pipes) Range: 0 or 1
When to Change |  | Change this parameter if you wish to take advantage of SVR4 style pipes. SVR3 pipes are the default because they provide faster performance.

### `nosuidshells`

Description |  | Some programs are written so that they perform actions that require superuser privilege. In order to perform these actions, they create a shell in which the user has superuser privilege. Such shells pose a certain manageable risk to system security, but application developers are generally careful to limit the actions taken by the application in these shells. The `nosuidshells` switch, when set to 0, allows these applications to create superuser-privileged shells. When set to any value other than 0, such shells are not permitted.
Value |  | Default: 1 (setuid shells not permitted)
When to Change |  | Change this switch to allow `setuid` shells.

### `posix_tty_default`

Description |  | The `posix_tty_default` parameter specifies whether the default IRIX system of line disciplines and settings for serial lines is used. These default settings are different from those specified by POSIX. If the value of this switch is 0, the default SGI line disciplines are used. If the value is set to 1, POSIX line disciplines and settings are used.
Value |  | Default: 0 Range: 0 or 1
When to Change |  | Change this switch if you need to use POSIX line disciplines.

### `restricted_chown`

Description |  | The `restricted_chown` parameter specifies whether the default SGI line disciplines are used. I switch allows you to decide whether you want to use a BSD UNIX style `chown(2)` system call or the System V style. Under the BSD version, only the superuser can use the `chown` system call to give away a file—to change the ownership to another user. Under the System V version, any user can give away a file or directory. If the value of the switch is 0, System V `chown` is enabled. If the value is not zero, BSD `chown` is enabled.
Value |  | Default: 0 Range: 0 or 1
When to Change |  | Change this switch to choose which behavior you prefer for the `chown(2)` system call.

### `use_old_serialnum`

Description |  | The `use_old_serialnum` parameter forces the kernel to use the old method (before IRIX Version 5) of calculating a 32-bit serial number for `sysinfo -s` when the parameter is set to 1. This variable affects only Onyx and Challenge L or XL systems.
Value |  | Default: 0 Range: 0 or 1
When to Change |  | Change this parameter on your Challenge or Onyx system if you need to use some older software that requires a 32-bit serial number.

### `subnetsarelocal`

Description |  | When the `subnetsarelocal` parameter is set to 1, all other subnets of a directly-connected subnetted network are considered to be local.
Value |  | Default: 0 Range: 0 or 1
When to Change |  | Change this parameter if no subnetted systems are directly connected to any external network, such as the Internet.

### `process_core_cpu_logging`

Description |  | The `process_core_cpu_logging` parameter, when set to 1, enables a special factory debugging mode that enables the logging of the CPU on which an exception occurs causing a process to core dump. By default, this feature is turned off, that is, a value of 0. This feature is useful for isolating hardware failures.
Value |  | Default: 0 (0x0) Range: 0 or 1
Notes |  | Produces a syslog message of the following format: "Process [<program name>] <pid> core dumped from trap generated on CPU <cpu number>" where <program name> is the name of the process, <pid> is the process id of the process, and <cpu number> is an integer indicating the physical CPU on which the exception was trapped.

## Timer Parameters

Timer parameters control the functioning of system clocks and timing facilities. The following parameters are defined:

- `fasthz` sets the profiling/fast `itimer` clock speed.

- `itimer_on_clkcpu` determines whether `itimer` requests are queued on the clock processor or on the running processor, respectively.

- `timetrim` specifies a signed number of nanoseconds. The system clock is adjusted every second by the signed number of nanoseconds specified.

### `fasthz`

Description |  | The `fasthz` parameter is used to set the profiling/fast `itimer` clock speed. `fasthz` may also be modified by using the `systune` command.
Value |  | Default: 1000 Range: 500-2500
When to Change |  | Change this parameter to give a finer or coarser grain for such system calls as `gettimeofday`, `getitimer`, and `settimer`.
Notes |  | On Indigo, Indigo2, and Indy systems, an acceptable value is 500, 1000, or 2500 (Hz). If the requested value is not one of these values, the default value of 1000 is used. On Challenge systems, the resolution of the hardware timer is 21 nanoseconds; therefore, any value smaller than 47 (MHz) is possible. On Octane systems, the `fasthz` value must be 1000. See also the `timers(5)` man page.

### `itimer_on_clkcpu`

Description |  | The `itimer_on_clkcpu` parameter is set to either 0 or 1, to determine whether `itimer` requests are queued on the clock processor or on the running processor, respectively.
Value |  | Default: 0 Range: 0 or 1
When to Change |  | If a process uses the `gettimeofday` call to compare the accuracy of the `itimer` delivery, then you should set this parameter to 1, to take advantage of the clock processor. If the `itimer` request is for the purpose of implementing a user frequency-based scheduler, then set this parameter to 0 to queue the requests on the current running processor.

### `timetrim`

Description |  | The `timetrim` parameter specifies a signed number of nanoseconds. The system clock is adjusted every second by the signed number of nanoseconds specified by it. This adjustment is limited to 3 milliseconds or 0.3%. The `timed` and `timeslave` utilities periodically place suggested values in `/var/adm/SYSLOG`.
Value |  | Default: 0 Range: 0-0.3% of a second (3 milliseconds)
When to Change |  | Change this parameter as suggested by `timed` and `timeslave`. Read the relevant man pages before taking any action.

## NFS Parameters

The following parameters control the kernel-level functions of the Network File System (NFS). Reducing these values is likely to cause significant performance decreases in your system:

- `portmap_timeout` sets the portmapper query timeout.

- `sm_timeout` sets the status monitor timeout.

- `` `GraceWaitTime` sets the NLM grace period wait time.

- `first_retry` sets the number of retries on the first contact with the portmapper.

- `normal_retry` sets the number of retries on later attempts to contact the portmapper.

- `lockd_grace_period` sets the grace period for NMI timeouts.

- `lock_share_requests` applies the corresponding IRIX file locks to share requests.

- `lockd_blocking_thresh` sets the number of daemons allowed to block before a new daemon is created.

- `nfs_portmon` specifies that clients may use any available port when the parameter is set to 0. If it is set to 1, clients must use only privileged ports.

- `svc_maxdupreq` s sets the number of cached NFS requests.

### `portmap_timeout`

Description |  | The `portmap_timeout` parameter specifies the portmapper query timeout, in 1/10 second increments.
Value |  | Default: 5 (0x5) Range: 1 to 200 (20 seconds)
Notes |  | Note that decreasing timeouts can severely degrade system performance.

### `sm_timeout`

Description |  | The `sm_timeout` parameter specifies the status monitor communication timeout in 1/10 second increments.
Value |  | Default: 5 (0x5) Range: 1 to 150 (15 seconds)
Notes |  | Note that decreasing normal and working timeouts can severely degrade system performance.

### `GraceWaitTime`

Description |  | The `GraceWaitTime` parameter specifies the NLM grace period, in seconds.
Value |  | Default: 5 (0x5) Range: 1 to 60 (1 minute)
Notes |  | Note that decreasing normal and working timeouts can severely degrade system performance.

### `first_retry`

Description |  | The `first_retry` parameter specifies the number of retries to be made for the first contact with the portmapper.
Value |  | Default: 1 (0x1) Range: 0 to 10000

### `normal_retry`

Description |  | The `normal_retry` parameter specifies the number of subsequent retries after communication has once been established with the portmapper.
Value |  | Default: 1 (0x1) Range: 0 to 10000

### `lockd_grace_period`

Description |  | The `lockd_grace_period` parameter specifies the NLM grace period, in seconds.
Value |  | Default: 45 (0x2d) Range: 1 to 3600 (1 hour)

### `lock_share_requests`

Description |  | The `lock_share_requests` parameter determines whether or not the system will apply IRIX file locks to share requests.
Value |  | Default: 0 (0x0) Range: 0 or 1

### `lockd_blocking_thresh`

Description |  | The `lockd_blocking_thresh` parameter specifies the number of daemons allowed to block before a new lock daemon will be spawned.
Value |  | Default: 0 (0x0) Range: 0 to 1000

### `nfs_portmon`

Description |  | The `nfs_portmon` parameter determines whether or not a client must use a privileged port for NFS requests. Only processes with superuser privilege may bind to a privileged port. The `nfs_portmon` parameter is binary. If it is set to 0, clients may use any available port. If it is set to 1, clients must use only privileged ports.
Value |  | Default: 0 Range: 0 or 1
When to Change |  | You should change this parameter only if it is absolutely necessary to maintain root privilege on your NFS mounted filesystems and you have checked each NFS client to be sure that it requests a privileged port. If there are any clients requesting non-privileged ports, they will be unable to mount the filesystems. Additionally, changing the value of `nfs_portmon` to 1 can give a false sense of security. A process must have `root` privilege in order to bind to a privileged port, but a single insecure machine compromises the security of this privilege check.

### `svc_maxdupreqs`

Description |  | The `svc_maxdupreqs` parameter sets the number of cached NFS requests.
Value |  | Default: 409 Range: 400-4096
When to Change |  | This parameter should be adjusted to the service load so that there is likely to be a response entry when the first retransmission comes in.

## Socket Parameters

This section describes socket parameters. Both UDS sockets and TCP/IP sockets are covered.

Under UNIX domain sockets, there is a pair of buffers associated with each socket in use. There is a buffer on the receiving side of the socket, and on the sending side. The size of these buffers represent the maximum amount of data that can be queued. The behavior of these buffers differs depending on whether the socket is a streams socket or a data-gram socket.

On a streams socket, when the sender sends data, the data is queued in the receive buffer of the receiving process. If the receive buffer fills up, the data begins queueing in the sendspace buffer. If both buffers fill up, the socket blocks any further data from being sent.

Under data-gram sockets, when the receive buffer fills up, all further data-grams sent are discarded and the error `EWOULDBLOCK` is generated. Because of this behavior, the default receive buffer size for data-gram sockets is twice that of the send buffer.

In order to improve networking performance with a large number of connections, TCP and UDP packet lookup is performed using a hashing scheme. The number of hash buckets used by the lookup code is normally computed at system boot time, and is based on the number of megabytes of available system RAM. UDP uses four buckets per megabyte of system RAM, plus one additional bucket. TCP uses eight buckets per megabyte of system RAM, plus one additional bucket.

Each hash bucket requires 24 bytes of RAM on a 32-bit system, and 48 bytes of RAM on a 64-bit system. So, for example, on a 128 MB Challenge XL system, UDP would use 513 hash buckets and TCP would use 1025 hash buckets. At 48 bytes per bucket, a total of 73824 bytes of system RAM are used hold hash table information when the default auto-configuration is used. On a 64 MB Indy, which has less memory and a smaller word size, the total memory consumption using the default values is 18456 bytes of system RAM.

If the default size is not optimal for your system, the table sizes can be changed using the `udp_hashtablesz` and `tcp_hashtablesz` parameters. Note that the kernel enforces some restrictions on the values that may be specified. The sizes do not include the dynamic space allocation for each TCP or UDP socket during its life time. These parameters are part of the `inpcb` parameter group, and are modified using `systune(1M)`.

The following parameters control sockets:

- `unpst_sendspace` specifies the UNIX domain socket stream send buffer size.

- `unpst_recvspace` specifies the UNIX domain socket stream receive buffer size.

- `unpdg_sendspace` specifies the UNIX domain socket data-gram send buffer size.

- `unpdg_recvspace` specifies the UNIX domain socket data-gram receive buffer size.

- `udp_hashtablesz` specifies the UNIX domain socket hash table size.

- `tcp_sendspace` specifies the TCP/IP socket send buffer size.

- `tcp_recvspace` specifies the TCP/IP socket receive buffer size.

- `tcp_hashtablesz` specifies the TCP/IP hash table size.

- `tcp_sack` enables selective acknowledgement for TCP.

### `unpst_sendspace`

Description |  | The `unpst_sendspace` parameter controls the default size of the `send` buffer on streams sockets.
Value |  | Default: 0x4000 (16KB)
When to Change |  | It is generally recommended that you change the size of socket buffers individually, since changing this parameter changes the send buffer size on all streams sockets, using a tremendous amount of kernel memory. Also, increasing this parameter increases the amount of time necessary to wait for socket response, since all sockets will have more buffer space to read. See the `setsockopt(2)` man page for more information on setting specific socket options.

### `unpst_recvspace`

Description |  | The `unpst_recvspace` parameter controls the default size of the receive buffer of streams sockets.
Value |  | Default: 0x4000 (16 KB)
When to Change |  | It is generally recommended that you change the size of socket buffers on an individual basis, since changing this parameter changes the receive buffer size on all streams sockets, using a tremendous amount of kernel memory. Also, increasing this parameter will increase the amount of time necessary to wait for socket response, since all sockets will have more buffer space to read. See the `setsockopt(2)` man page for more information on setting specific individual socket options.

### `unpdg_sendspace`

Description |  | The `unpdg_sendspace` parameter controls the size of a data-gram that can be sent over a socket.
Value |  | Default: 0x2000 (8 KB)
When to Change |  | Data-gram sockets operate slightly differently from streams sockets. When a streams socket fills the receive buffer, all data is then sent to the send buffer, and when the send buffer fills up, an error message is issued. Data-gram sockets allow data-grams to fill the receive buffer, and when the receive buffer is full, all future data-grams are discarded, and the error `EWOULDBLOCK` is generated. Therefore, the `unpdg_sendspace` parameter serves only to limit the size of a data-gram to not more than can be received by the receive buffer. Note that the default data-gram socket receive buffers are twice the size of the default data-gram send buffers, thus allowing the process to appear the same as the streams sockets. It is generally recommended that you not change the size of this parameter without also changing the default receive buffer size for data-gram sockets. If you raise the value of this parameter (`unpdg_sendspace`) without raising the receive buffer size (`unpdg_recvspace``)`, you will allow the sending half of the socket to send more data than can be received by the receiving half. Also it is generally recommended that socket buffer sizes be set individually via the `setsockopt(2)` system call. See the `setsockopt(2)` man page for more information on setting specific individual socket options.

### `unpdg_recvspace`

Description |  | The `unpdg_recvspace` parameter controls the default size of data-gram socket receive buffers.
Value |  | Default: 0x4000 (16 KB)
When to Change |  | It is generally recommended that you change the size of socket buffers individually, since changing this parameter changes the receive buffer size on all data-gram sockets, using a tremendous amount of kernel memory. Also, increasing this parameter increases the amount of time necessary to wait for socket response, since all sockets will have more buffer space to read. See the `setsockopt(2)` man page for more information on setting specific individual socket options.

### `udp_hashtablesz`

Description |  | The `udp_hashtablesz` parameter controls the size of the UDP hash table.
Value |  | Default: 0 (Auto-configure) Range: 64-2048
When to Change |  | This should not normally need to be changed, but might be changed in order to reduce the consumption of system RAM on systems that are not used to handle large numbers of networking applications, or to increase the number of hash buckets on systems that primarily provide networking services.Using a zero value specifies that the table is to be sized based on system RAM. A non-zero value specifies the number of hash buckets to use for UDP. The system automatically adjusts this number to support the requirements of the hashing algorithm. For example, entering a value of 512 will create 513 buckets.
Restrictions |  | The system silently enforces a minimum value of 64 hash buckets and a maximum value of 2048 hash buckets.

### `tcp_sendspace`

Description |  | The `tcp_sendspace` parameter controls the default size of the send buffer on TCP/IP sockets. There is a pair of buffers associated with each socket in use. There is a buffer on the receiving side of the socket, and on the sending side. The size of these buffers represent the maximum amount of data that can be queued.
Value |  | Default: 60 KB Range: 0-512 KB
When to Change |  | The `tcp_sendspace` parameter may require tuning for slow throughput links, and for compatibility with TCP implementations based on 4.2BSD. For slow throughput links (such as lower speed PPP or SLIP connections), lower the value of this and the `tcp_recvspace` parameters until the best performance level is found. Very slow links such as PPP or SLIP over modems usually find a 3 KB or 4 KB buffer size to be the most efficient. The `tcp_sendspace` parameter may require tuning for slow throughput links, and for compatibility with TCP implementations based on 4.2BSD. For slow throughput links (such as a Wide Area Net with a lower speed PPP or SLIP component), lower the value of this and the `tcp_recvspace` parameters on systems where the connection goes from fast (Ethernet, FDDI, etc.) to slow (PPP or SLIP) until the best performance level is found. Very slow links such as PPP or SLIP over modems usually find a 3 KB or 4 KB buffer size to be the most efficient. Conversely, high speed connections may profit from increasing the buffer size incrementally from 60 KB until maximum performance is achieved. See the `setsockopt(2)`man page for more information on setting specific socket options.

### `tcp_recvspace`

Description |  | The `tcp_recvspace` parameter controls the default size of the TCP/IP receive buffer. There is a pair of buffers associated with each socket in use. There is a buffer on the receiving side of the socket, and on the sending side. The size of these buffers represent the maximum amount of data that can be queued.
Value |  | Default: 60 KB Range: 0-512 KB
When to Change |  | The `tcp_recvspace` parameter may require tuning for slow throughput links, and for compatibility with TCP implementations based on 4.2BSD. For slow throughput links (such as a Wide Area Net with a lower speed PPP or SLIP component), lower the value of this and the`tcp_sendspace` parameters on systems where the connection goes from fast (ethernet, FDDI, and so on) to slow (PPP or SLIP) until the best performance level is found. Very slow links such as PPP or SLIP over modems usually find a 3 KB or 4 KB buffer size to be the most efficient. Conversely, high speed connections may profit from increasing the buffer size incrementally from 60 KB until maximum performance is achieved. See the `setsockopt(2)` man page for more information on setting specific individual socket options.

### `tcp_hashtablesz`

Description |  | The `tcp_hashtablesz` parameter controls the size of the TCP hash table.
Value |  | Default: 0 (Auto-configure) Range: 64-8192
When to Change |  | The `tcp_hashtablesz` parameter should not normally need to be changed, but might be changed in order to reduce the consumption of system RAM on systems that are not used to handle large numbers of networking applications, or to increase the number of hash buckets on systems that primarily provide networking services. Using a zero value specifies that the table is to be sized based on system RAM. A non-zero value specifies the number of hash buckets to use for TCP. The system automatically adjusts this number to support the requirements of the hashing algorithm. For example, entering a value of 512 will create 1025 buckets, since TCP uses the extra space for processing connections in the `TIME-WAIT` state.
Restrictions |  | The system silently enforces a minimum value of 64 hash buckets and a maximum value of 8192 hash buckets.

### `tcp_sack`

Description |  | The `tcp_sack` parameter enables selective acknowledgment for TCP, as per RFC 2018. This capability can provide significant increase in TCP performance over error prone or lossy connections.
Value |  | Default: 1 Range: 0, 1
When To Change |  | Turn this parameter off (set to 0) only if you have old network gear which does not properly process unknown TCP options.

## VINO Parameter

This section describes the Indy Video In No Out (VINO) tunable parameter, `vino_mtune_dmrbpages`, which limits the size of the direct memory access (DMA) descriptor table used by the VINO video capture.

### `vino_mtune_dmrbpages`

Description |  | The `vino_mtune_dmrbpages` parameter limits the size of the DMA descriptor table used by the VINO video capture. This in turn limits how many pages allocated to the Digital Media Ring Buffers (DMRB) are usable when capturing video. The number of pages in `vino_mtune_dmrbpages` is what the DMRB size specifically for VINO is limited to when allocated.
Value |  | Default: 0 (auto-configure) If this parameter is set to zero, then a default based on the amount of memory available at run time is used. If a limit of less than that is desired, set this variable to the maximum number of pages that the ring buffers can use. A value of -1 indicates do not preallocate any space for VINO DMA descriptors.
Notes |  | Note that if a DMA descriptor table size is needed that is greater than the size specified here and cannot be allocated contiguously at run time (possibly due to memory fragmentation), then the video transfer will not be started, and will return an `ENOMEM` error. The error recovery is to attempt the capture with a smaller DMRB.

## Large Page Parameters

Large pages must be allocated early on and reserved if they are to be used. The values specified in the`nlpages_`x parameters refer to the number of large pages of size x. When these are set, the kernel will attempt to allocate these counts of pages of the appropriate size.

The following parameters pertain to large page allocation:

- `nlpages_256k` specifies the number of 256KB pages to be allocated.

- `nlpages_1m` specifies the number of 1 MB pages to be allocated.

- `nlpages_4m` specifies the number of 4 MB pages to be allocated.

- `nlpages_16m` specifies the number of 16 MB pages to be allocated.

### `nlpages_256k`

Description |  | The `nlpages_256k` parameter specifies the number of 256 KB pages to be allocated.
Value |  | Default: 0 Range: 0-64

### `nlpages_1m`

Description |  | The `nlpages_1m` parameter specifies the number of 1 MB pages to be allocated.
Value |  | Default: 0 Range: 0-64
When to Change |  | The recommended initial value for large (64 processors or greater) systems is 0.

### `nlpages_4m`

Description |  | The `nlpages_4m` parameter specifies the number of 4 MB pages to be allocated.
Value |  | Default: 0 Range: 0-64

### `nlpages_16m`

Description |  | The `nlpages_16m` parameter specifies the number of 16 MB pages to be allocated.
Value |  | Default: 0 Range: 0-64

## Extended Accounting Parameters

The following parameters control system accounting features. The parameters are:

- `do_procacct` controls BSD process accounting.

- `do_extpacct` controls extended process accounting.

- `do_sessacct` controls array session accounting.

- `min_local_paggid` controls the first array session handle that can be assigned by the kernel.

- `max_local_paggid` controls the largest array session handle that can be assigned by the kernel before wrapping back to `min_local_paggid`.

- `asmachid` controls the machine ID for generating global ASHs.

- `dfltprid` controls the default project ID for special sessions.

### `do_procacct`

Description |  | The `do_procacct` parameter, when set to 1, directs the system to perform BSD system accounting. When set to 0, the system does not perform the accounting, overriding the `acct(2)` system call.
Value |  | Default: 1 Range: 0-1

### `do_extpacct`

Description |  | The `do_extpacct` parameter, when set to 1, directs the system to perform extended process accounting. When set to 0, the system does not perform the accounting.
Value |  | Default: 0 Range: 0-1

### `do_sessacct`

Description |  | The `do_sessacct` parameter, when set to 1, directs the system to perform array session accounting when a process exits. When set to 0, the system does not perform the accounting.
Value |  | Default: 0 Range: 0-1

### `min_local_paggid`

Description |  | The `min_local_paggid` parameter specifies the first array session handle that can be assigned by the kernel.
Value |  | Default: 1 Range: 1-0x7ffffff00

### `max_local_paggid`

Description |  | The `max_local_paggid` parameter specifies the largest array session handle that can be assigned by the kernel before wrapping back to `min_local_paggid`.
Value |  | Default: 65535 Range: 255 -0x7ffffffff

### `asmachid`

Description |  | The `asmachid` parameter specifies the system ID for generating global ASHs. No other system in an array should have the same system ID. If 0 is specified, the kernel will only generate local ASHs.
Value |  | Default: 0 Range: 0 -0x7fff

### `dfltprid`

Description |  | The `dfltprid` parameter specifies the default project ID for special system sessions and other sessions that bypass ordinary project ID assignment.
Value |  | Default: 0 Range: 0 -0x7fffffffffffffff

## NUMA Parameters

The following parameters are memory migration parameters that are valid only on NUMA machines such as Origin2000 systems and SGI 3000 family servers. The parameters are:

- `numa_migr_default_mode` defines the default migration mode.

- `` `numa_migr_default_threshold` defines the minimum difference between the local and any remote counter needed to generate a migration request interrupt.

- `` `numa_migr_threshold_reference` defines the pegging value for the memory reference counters.

- `` `numa_migr_min_maxradius` specifies the minimum `maxradius` for migration to be turned on.

- `` `numa_migr_min_distance` specifies the minimum distance required by the Node Distance Filter in order to accept a migration request.

- `numa_zone_radius_max` specifies the maximum radius value for use by the zone allocator.

- `numa_migr_vehicle` defines what device the system should use to migrate a page.

- `numa_refcnt_default_mode` defines the default extended reference counter mode.

- `` `numa_refcnt_overflow_threshold` defines the count at which the hardware reference counters notify the operating system of a counter overflow in order for the count to be transfered into the (software) extended reference counters.

- `` `numa_migr_memory_low_threshold` defines the threshold at which the Memory Pressure Filter starts rejecting migration requests to a node.

- `` `numa_migr_memory_low_enabled` enables or disables the Memory Pressure Filter.

- `numa_migr_freeze_enabled` enables or disables the freezing operation in the Bounce Control Filter.

- `numa_migr_freeze_threshold` defines the threshold at which a page is frozen.

- `` `numa_migr_melt_enabled` enables or disables the melting operation in the Bounce Control Filter.

- `numa_migr_melt_threshold` unfreezes a page when a migration counter goes below this threshold.

- `numa_migr_bounce_control_interval` defines the period for the loop that ages the migration counters and the dampening counters.

- `numa_migr_dampening_enabled` enables or disables migration dampening.

- `numa_migr_dampening_factor` defines the number of migration requests needed for a page before migration is actually executed.

- `mem_tick_enabled` enables or disables the loop that executes the Migration Control Periodic Operation from `clock.c/`.

- `` `mem_tick_base_period` defines the number of 10 ms system ticks in one `mem_tick`.

- `numa_migr_unpegging_control_enabled` enables or disables the unpegging periodic operation.

- `numa_migr_unpegging_control_interval` defines the period for the loop that unpegs the hardware memory reference counters.

- `numa_migr_unpegging_control_threshold` defines the hardware memory reference counter value at which the system considers the counter to be pegged.

- `numa_migr_traffic_control_enabled` enables or disables the Traffic Control Filter.

- `numa_migr_traffic_control_interval` defines the traffic control period.

- `numa_migr_traffic_control_threshold` defines the traffic control threshold for kicking the batch migration of enqueued migration requests.

### `numa_migr_default_mode`

Description |  | The `numa_migr_default_mode` parameter defines the default migration mode.
Value |  | Default: 2 Range: 0-4 `0:` `MIGR_DEFMODE_DISABLED` Migration is completely disabled. Users cannot use migration. `1:` `MIGR_DEFMODE_ENABLED` Migration is always enabled. Users cannot disable migration. `2:` `MIGR_DEFMODE_NORMOFF` Migration is normally off. Users can enable migration for an application. `3:` `MIGR_DEFMODE_NORMON` Migration is normally on. Users can disable migration for an application. `4:` `MIGR_DEFMODE_LIMITED` Migration is normally off for machine configurations with a maximum NUMAlink distance less than `numa_migr_min_maxradius` (defined below). Migration is normally on otherwise. Users can override this mode.

### `numa_migr_default_threshold`

Description |  | The `numa_migr_default_threshold` parameter defines the minimum difference between the local and any remote counter needed to generate a migration request interrupt.
    if ( (remote_counter - local_counter) >= ((numa_migr_threshold_reference_value / 100) * numa_migr_default_threshold)){send_migration_request_intr(); }
Value |  | Default: 50 Range: 0-100

### `numa_migr_threshold_reference`

Description |  | The `numa_migr_threshold_reference` parameter defines the pegging value for the memory reference counters. It is machine configuration dependent. For Origin2000 systems, it can take the following values:
Value |  | Default: 0 Range: 0-1 `0:` `MIGR_THRESHREF_STANDARD``=` Threshold reference is 2048 (11 bit counters). This is the maximum threshold allowed for systems with STANDARD DIMMS. `1:` `MIGR_THRESHREF_PREMIUM``=` Threshold reference is 524288 (19-bit counters). This is the maximum threshold allowed for systems with *all* premium SIMMS.

### `numa_migr_min_maxradius`

Description |  | The `numa_migr_min_maxradius` parameter specifies the minimum `maxradius` for migration to be turned on. This parameter is used if `numa_migr_default_mode` has been set to mode `4` (`MIGR_DEFMODE_LIMITED`). For this mode, migration is normally off for machine configurations with a maximum NUMAlink distance less than `numa_migr_min_maxradius`. Migration is normally on otherwise.
Value |  | Default: 2

### `numa_migr_min_distance`

Description |  | The `numa_migr_min_distance` parameter specifies the minimum distance required by the Node Distance Filter in order to accept a migration request.
Value |  | Default: 1

### `numa_zone_radius_max`

Description |  | The `numa_zone_radius_max` parameter specifies the maximum radius value for use by the zone allocator.
Value |  | Default: 2

### `numa_migr_vehicle`

Description |  | The `numa_migr_vehicle` parameter defines what device the system should use to migrate a page. The value 0 selects the Block Transfer Engine (BTE) and a value of 1 selects the processor. When the BTE is selected, and the system is equipped with the optional poison bits, the system automatically uses Lazy TLB Shootdown Algorithms.
    MIGR_VEHICLE_IS_BTE           0
    MIGR_VEHICLE_IS_TLBSYNC       1
Assume migr_vehicle to be BTE to start with. If the system has no BTE, NUMA initialization code will change this to TLBsync. In addition, it will be changed to TLBsync if the processor revision is not suitable to use BTE.
Value |  | Default: 1

### `numa_refcnt_default_mode`

Description |  | The `numa_refcnt_default_mode` parameter defines the default extended reference counter mode. It can take the following values:
Value |  | Default: 0 Range: 0-3 `0:` `REFCNT_DEFMODE_DISABLED` Extended reference counters are disabled; users cannot access the extended reference counters (refcnt(5)). `1:` `REFCNT_DEFMODE_ENABLED` Extended reference counters are always enabled; users cannot disable them. `2:` `REFCNT_DEFMODE_NORMOFF` Extended reference counters are normally disabled; users can disable or enable the counters for an application. `3:` `REFCNT_DEFMODE_NORMON` Extended reference counters are normally enabled; users can disable or enable the counters for an application.

### `numa_refcnt_overflow_threshold`

Description |  | The `numa_refcnt_overflow_threshold` parameter defines the count at which the hardware reference counters notify the operating system of a counter overflow in order for the count to be transferred into the (software) extended reference counters. It is expressed as a percentage of the threshold reference value defined by `numa_migr_threshold_reference`.
Value |  | Default: 50

### `numa_migr_memory_low_threshold`

Description |  | The `numa_migr_memory_low_threshold` parameter defines the threshold at which the Memory Pressure Filter starts rejecting migration requests to a node. This threshold is expressed as a percentage of the total amount of physical memory in a node.
Value |  | Default: 20

### `numa_migr_memory_low_enabled`

Description |  | The `numa_migr_memory_low_enabled` parameter enables or disables the Memory Pressure Filter.
Value |  | Default: 1

### `numa_migr_freeze_enabled`

Description |  | The `numa_migr_freeze_enabled` parameter enables or disables the freezing operation in the Bounce Control Filter.
Value |  | Default: 0

### `numa_migr_freeze_threshold`

Description |  | The `numa_migr_freeze_threshold` parameter defines the threshold at which a page is frozen. This parameter is expressed as a percent of the maximum count supported by the migration counters (7% for Origin2000 systems).
Value |  | Default: 20

### `numa_migr_melt_enabled`

Description |  | The `numa_migr_melt_enabled` parameter enables or disables the melting operation in the Bounce Control Filter.
Value |  | Default: 0

### `numa_migr_melt_threshold`

Description |  | The `numa_migr_melt_threshold` parameter unfreezes a page when a migration counter goes below this threshold. This parameter is expressed as a percent of the maximum count supported by the migration counters (7% for Origin2000 systems).
Value |  | Default: 90

### `numa_migr_bounce_control_interval`

Description |  | The `numa_migr_bounce_control_interval` parameter defines the period for the loop that ages the migration counters and the dampening counters. It is expressed in terms of number of mem_ticks (the `mem_tick` unit is defined by `mem_tick_base_period` below). If it is set to 0, the system processes 4 pages per `mem_tick`. In this case, the actual period depends on the amount of physical memory present in a node.
Value |  | Default: 0

### `numa_migr_dampening_enabled`

Description |  | The `numa_migr_dampening_enabled` parameter enables or disables migration dampening.
Value |  | Default: 0

### `numa_migr_dampening_factor`

Description |  | The `numa_migr_dampening_factor` parameter defines the number of migration requests needed for a page before migration is actually executed. It is expressed as a percent of the maximum count supported by the migration-request counters (3% for Origin2000 systems).
Value |  | Default: 90

### `mem_tick_enabled`

Description |  | The `mem_tick_enabled` parameter enables or disables the loop that executes the Migration Control Periodic Operation from clock.c/.
Value |  | Default: 1

### `mem_tick_base_period`

Description |  | The `mem_tick_base_period` parameter defines the number of 10 ms system ticks in one `mem_tick`.
Value |  | Default: 1

### `numa_migr_unpegging_control_enabled`

Description |  | The `numa_migr_unpegging_control_enabled` parameter enables or disables the unpegging periodic operation.
Value |  | Default: 1

### `numa_migr_unpegging_control_interval`

Description |  | The `numa_migr_unpegging_control_interval``` parameter defines the period for the loop that unpegs the hardware memory reference counters. It is expressed in terms of number of `mem_tick` `s` (the `mem_tick` unit is defined by `mem_tick_base_period`). If it is set to 0, the system processes 8 pages per `mem_tick`. In this case, the actual period depends on the amount of physical memory present in a node.
Value |  | Default: 0

### `numa_migr_unpegging_control_threshold`

Description |  | The `numa_migr_unpegging_control_threshold` parameter defines the hardware memory reference counter value at which the system considers the counter to be pegged. It is expressed as a percent of the maximum count defined by `numa_migr_threshold_reference`.
Value |  | Default: 90

### `numa_migr_traffic_control_enabled`

Description |  | The `numa_migr_traffic_control_enabled` parameter enables or disables the Traffic Control Filter. This is an experimental module, and therefore it should always be disabled.
Value |  | Default: 0

### `numa_migr_traffic_control_interval`

Description |  | The `numa_migr_traffic_control_interval` parameter defines the traffic control period. This is an experimental module.
Value |  | Default: 400

### `numa_migr_traffic_control_threshold`

Description |  | The `numa_migr_traffic_control_threshold` parameter defines the traffic control threshold for kicking the batch migration of enqueued migration requests. This is an experimental module.
Value |  | Default: 80

## Page Replication Parameter

The page replication parameter is `` `numa_kernel_replication_ratio, which` specifies the ratio of memory nodes to kernel text images.

### `numa_kernel_replication_ratio`

Description |  | The `` `numa_kernel_replication_ratio` parameter specifies the ratio of memory nodes to kernel text images. There will always be a copy on the master node and also on every other n of the other nodes. 0 means do not replicate. There is always a copy on the master node, and for a ratio n, copies are made on every n of the other nodes. The default value is 1, which causes copies of the kernel text to be made on every node.
Value |  | Default: 1

## Migration Memory Queue Parameters

The following parameters control the migration memory queue. The parameters are:

- `numa_migr_coaldmigr_mech` defines the migration execution mode for memory coalescing migrations.

- `numa_migr_user_migr_mech` defines the migration execution mode for user-requested migrations.

- `numa_migr_auto_migr_mech` defines the migration execution mode for memory reference counter-triggered migrations.

### `numa_migr_coaldmigr_mech`

Description |  | The `numa_migr_auto_migr_mech` parameter defines the migration execution mode for memory coalescing migrations. A value of 0 specifies immediate, a value of 1 specifies delayed. Only the Immediate Mode (0) is currently available.
Value |  | Default: 0 Range: 0-1

### `numa_migr_user_migr_mech`

Description |  | The `numa_repl_mem_lowmark` parameter defines the migration execution mode for user-requested migrations. A value of 0 specifies immediate, a value of 1 specifies delayed. Only the Immediate Mode (0) is currently available.
Value |  | Default: 0 Range: 0-1

### `numa_migr_auto_migr_mech`

Description |  | The `numa_migr_auto_migr_mech` parameter defines the migration execution mode for memory reference counter-triggered migrations. A value of 0 specifies immediate, a value of 1 specifies delayed. Only the Immediate Mode (0) is currently available.
Value |  | Default: 0 Range: 0-1

## XVM Parameters

XVM Volume Manager tunable parameters are in the `var/sysgen/mtune/xvm` file. This file includes parameters that control the mirror revive resources for XVM logical volumes. If system performance of mirror revives seems slow, consider reconfiguring these resources. The XVM mirror revive resource parameters are dynamic variables that may be modified without a system reboot by using the `systune(1M)` command.

The following XVM mirror revive resource parameters are available:

- `xvm_max_revive_threads` controls how many processes will revive at one time.

- `xvm_max_revive_rsc` controls the number of parallel I/O processes that are used for the revive process.

As a general guideline, do the following:

- Increase the threads and resources to revive as quickly as possible if the resulting performance impact on normal I/O processes is acceptable.

- Decrease the threads if the XLV and XVM Volume Managers are sharing the same system.

- Decrease the resources to have a smaller impact on a particular filesystem.

### `xvm_max_revive_threads`

Description |  | The `xvm_max_revive_threads` parameter controls how many processes will revive at one time.
Value |  | Default: 4 Range: 1 to 12
When to Change |  | Decrease the number of threads if XLV and XVM mirrored logical volumes are used on the same system. This change will prevent the XVM Volume Manager from stealing too many resources from the XLV Volume Manager. Or increase the number of threads to have more revives run in parallel.

### `xvm_max_revive_rsc`

Description |  | The `xvm_max_revive_rsc` parameter controls the number of parallel I/O processes that are used for the revive process.
Value |  | Default: 5 Range: 1 to 10
When to Change |  | Decreasing the number of parallel I/O processes causes less interference with an open file system at the cost of increasing the total time to revive the data.

## CXFS Parameters

The following parameters are available for CXFS:

- `cms_reset_timeout`

  Specifies the number of seconds to wait for `clconfd` to acknowledge a reset request.

- `cms_reset_timeout_action`

  Specifies the action to be taken when `clconfd` does not acknowledge a reset request (determined by `cms_reset_timeout`)

For more information on the CXFS system tunable parameters, see Chapter 6 “Administration and Maintenance”, in the CXFS Software Installation and Administration Guide.

## Core File Parameter

### `coremask`

Description |  | The `coremask` parameter is set in the `/var/sysgen/mtune/kernel` file to determine what kind of permissions a core file will receive.
Value |  | Default: 0
|  | Range: Minimum `0` - Maximum `0177`
When to Change |  | Currently, when a process creates a core file, it uses the umask of the owner of the process to determine the permissions on the core file. This can lead to core files containing sensitive information being created with world readable permissions. This `systune` variable allows the system administrator to limit access to core files. The default is 0, which is the current behavior. However, if the `coremask` variable is set to some other value, it uses that number as the umask and ignores the umask of the owner of the process. For example, if `coremas`k is set to 0`177` and the owner of the process has a umask of `022`, the permissions set on the core file will be `600` instead of `644`. This variable assumes that the number entered is octal.

Prev | Table of Contents | Next
Chapter 10. System Performance Tuning |  | Appendix B. Troubleshooting System Configuration Using System Error Messages