The amount of virtual memory held by users or an application (this is a measure at the lnode level of all processes' virtual memory usage)
The amount of virtual memory held by a group of users or an application (this is a measure at the group header lnode level of all processes' virtual memory usage where those processes are attached to the group header and/or to its children)
The amount of virtual memory held by an individual process
The number of processes that a user/lnode can run concurrently
The system attributes used to record virtual memory usage and assign limits to it are:
The memory.myusage attribute of an lnode is equal to the sum of the virtual memory usage of all processes currently attached to the lnode.
The memory.usage attribute of an lnode is equal to the sum of its memory.myusage attribute and the memory.usage attributes of its child lnodes.
The memory.limit attribute is applied to the memory.usage attribute; it limits the combined memory usage of all processes attached to the lnode and all member lnodes.
The system attribute used to record process usage and assign limits to it is:
The memory.plimit attribute of an lnode is a per-process limit that is applied separately to the memory usage of each process attached to it or to any of its members.
Whenever a process attempts to increase its memory size, it is subject to the memory limits (total and per-process) of the lnode to which it is attached. There are five means by which a process can attempt to increase its memory size:
Calling an allocation routine, such as malloc(3C), which results in an invocation of the sbrk(2) system call. If a memory limit is exceeded, the call will return an error with errno set to ENOMEM.
Expanding the stack and causing a stack fault, which would normally cause an extra page of memory to be given to the process. If a memory limit is exceeded, the process will be sent a SIGSEGV signal.
Using fork(2). The child address space is duplicated while it is still owned by the parent process. During duplication, the new address space will not exceed the memory.plimit since the parent must already be within this limit; however, the allocation is subject to the memory.limit.
Using exec(2). During an exec, memory usage first decreases as the old address space is discarded. However, if the address space of the new program is larger, and causes a limit to be exceeded, the exec can fail.
The dynamic reconfiguration (DR) feature available on the Enterprise 10000, Sun Fire 15K, and Sun Fire 12K systems has limited impact on the virtual memory limits imposed on lnodes. Specifically, DR makes it possible to add or remove physical memory from the system while the system is up and running. (The system's pool of virtual memory includes all of the physical memory, plus the swap space configured into the system.) Additionally, the swap(1M) command can be used on any Solaris system to add (-a) or delete (-d) swap space from the system. Thus, the total amount of virtual memory can grow or shrink during operation.
This has an indirect impact on the virtual memory limits imposed by Solaris Resource Manager. Because virtual memory is managed in absolute units (rather than shares), the effective limits do not change when the system's resources change during operation. (Note that this behavior is different from the dynamic reconfiguration of processors, as discussed in Dynamic Reconfiguration.)
The system attributes used to administer process usage (the number of processes) are:
The process.myusage attribute of an lnode is equal to the number of processes attached to the lnode.
The process.usage attribute of an lnode is equal to the sum of its process.myusage attribute and the process.usage attributes of its child lnodes.
The process.limit attribute is a limit that applies to the process.usage attribute of an lnode; it limits the number of processes that can be attached to the lnode and all member lnodes concurrently.
The fork(2) and vfork(2) system calls are used to create new processes. If this would cause the process limit to be exceeded, the system call fails, returning an EAGAIN error. Most programs interpret EAGAIN as meaning a temporary shortage of system resources and try the fork again, perhaps after a short sleep. If the fork failure is due to a Solaris Resource Manager limit, this can lead to looping for an indefinite amount of time because EAGAIN will be returned on each retry until the limit is fixed for the affected lnode.