|Parameter||Dflt 64/256/1024||Min 64/256/1024||Max 64/256/1024||Auto|
A process can change the applicable values using the priocntl system call or command interface.
However, since these parameters affect memory resource distribution among processes, ordinarily the PLOCK privilege is required for a process that changes these parameters. For some trusted systems, it is necessary to waive this requirement, and this is made possible by the AGING_TUNE_PRIV tunable. Typically, this tunable is set to ``0''; if unprivileged processes are to be allowed to change their aging parameters, then this tunable should be set to ``1''.
DEDICATED_MEMORY is used in conjunction with GENERAL_MEMORY. See ``Managing Large Physical Memory'' for information abut using the DEDICATED_MEMORY parameter to configure Large Physical Memory (LPM).
static-kernel-sz, calloc()ed-memory and per-engine-memory are memory the kernel consumes at boot time. gp = general purpose memory.
If kpgseg (segkvn) is too small, performance might decrease because of an increased cost for allocating kernel virtual space. Also, performance might decrease on a multiprocessing system due to an increased requirement for TLB (Translation Lookaside Buffer) shootdown. In some cases driver modules might not load. Moreover, in extreme cases, the system or some LWPs could hang because of a wait for kernel virtual space that is not available. Under any of these circumstances, you may want to increase kpgseg (segkvn) virtual space. Conversely, if kpgseg (segkvn) is underutilized, you might want to decrease its size to save some of the physical memory needed to support kernel virtual.
Together, these two tunable parameters controlled the size
of the segkmap kernel virtual segment.
This segment is used by filesystems to cache the data accessed through the
interfaces, file directory data, as well as data accessed by NFS on
the server side.
By default, the maximum size of segkmap is given by:
SEGMAP_BYTES + (gp * SEGMAP_PERCENT)
where gp was the size of the general purpose memroy pool. The actual size of segkmap could be smaller because of limited kernel virtual space. If segkmap is too small for the load, local file or remote NFS performance could suffer. Conversely, if segkmap is underutilized, and more kernel virtual space is required in another kernel virtual segment, then it is advisable to decrease the size of segkmap.
The effect of slowing down segkmap aging is to increase filesystem performance but at the expense of decreased available memory for other uses (for example, for process pages).
SEGKMEM_BYTES is the minimum size of the kpgseg kernel virtual segment. This segment is used by the kernel memory allocator for all its memory; by the hardware address translation layer (HAT) for its page tables; and by various drivers for both temporary and permanent mappings.
SEGKMEM_PSE_BYTES will be rounded up to the next 4MB boundary. SEGKMEM_PSE_BYTES should be less than SEGKMEM_BYTES, since some KMA requests (for DMA-accessible buffers, or buffers with special alignment or boundary restrictions) can only be satisfied with non-PSE backed KMA. The system will automatically reduce SEGKMEM_PSE_BYTES so that at least 2 megabytes of non-PSE backed KMA is available.
|Parameter||Dflt 64/256/1024||Min||Max 64/256/1024||Auto|
It controls when swap outs begin. It specifies the low water mark of free memory (in pages) for swapping to start swapping out processes. The activity of the pageout daemon is also controlled by this parameter.
If multiple swap devices exist and can be accessed in parallel so that the peak sustainable paging rate can scale with the number of swap devices, then this tunable should be set to ``1''. In this case, as each new swap device is added, the system increases its estimate of peak paging throughput. If one or more swap devices exist but the peak sustainable paging rate does not increase either because of controller limitations or because the swap devices are on the same physical media, then this tunable should be set to ``0''.
In general, UVIRT_EXTENSION should only be set if the system is going to run extremely large programs, such as databases with large (3GB or more) shared memory segments. One typical case in which a non-zero value might be useful is when running large programs on machines with large amounts of physical memory (4GB or more) where much of that memory is dedicated. In such cases, UVIRT_EXTENSION might allow some applications to use the physical memory of the machine more efficiently.