Setting " swapmem_on 0 " has the effect of turning off pseudo-swap . This means that all the configured swap space is derived from the actual swap devices configured by the administrator. In order to use main memory, the swap reservation algorithm requires some swap space to be available. This has the implication that an administrator must configure at least as much swap space as main memory; otherwise , the swap reservation algorithm will not allow the use of all main memory; it cannot reserve swap space because not enough swap space was configured. This is not a good situation to be in.
A2:
The memory allocated to the dynamic buffer cache is treated like any other memory usage. Memory will be reclaimed from the dynamic buffer cache when the vhand process is activated when free memory drops below lotsfree .
A3:
When pages are being paged-out to a swap device, the system is experiencing significant memory pressure. If the system were to allocate single pages from swap devices, it would be an additional task for the system to undertake. When memory pressure is high, the last thing you want is the operating system performing additional, laborious, and CPU-expensive processing. The idea behind a swchunk is to simplify the allocation of swap space and to allocate a significant piece of swap space. In this way, the operating system can track how many pages of data it can accommodate in a single swchunk (2MB = 512 paged, by default). If a swchunk becomes fully utilized, a new swchunk can be allocated to the process. An added bonus is that the data pages for an individual process that have been paged-out are in close proximity to each other, should the process need them again. All of these attributes make it far easier for the operating system to handle chunks of swap space than having to find and allocate individual pages every time a page of data needs to page-out.
A4:
Swapping an entire process out to disk can be a very IO- and CPU- intensive task; in other words, swapping out a 1GB process may render the system unusable while the swap-out is occurring. The job of the swapper process is simply to deactivate processes when memory pressure dictates it. By deactivating a process, it is taken off the run queue and not allowed to run. The vhand daemon can now age and effectively steal all the pages for the deactivated process; the process can un-age a page, as it is not allowed to run while being deactivated. The swapper process has built-in logic to choose noninteractive processes over interactive ones; to choose sleeping processes over running ones; and to choose processes that have been running longest over newer processes. Similar logic applies when swapper is asked to re-activate processes.
A5:
Dump devices need to be contiguous, because the routines that write the crashdump to disk cannot make any assumptions about the structure of an underlying dump device. The contiguous nature of a dump device means the device is guaranteed to have physical block 1 follow on from block 0. This makes writing a crashdump to disk a relatively simple process. Another reason for this requirement is that the code used to write the crashdump need not be aware of any device-specific characteristics that may be unique to VxVM and/or LVM . This makes the crashdump code device-independent. There is also the possibility that the crashdump may have been caused by the volume management software, which we are now relying on to write the crashdump to disk. Because of this subsequent device-independence, a dump device cannot use any special volume management features such as mirroring (even though mirroring a dump device may seem like a good idea).
