| The pseudo-swap approach is one of the least understood features of the HP-UX kernel; hopefully, we can make you comfortable with its purpose and function. Pseudo-swap is enabled in the HP-UX kernel by setting the kernel parameter swapmemon to 1 (this is the default for freshly installed systems). With pseudo-swap enabled, the swap reservation limit is adjusted to include all physical swap plus 75 percent of the system's available memory (87 percent on the latest release). This has been described as "using physical memory for swap space." While there is a basic truth to this statement, it doesn't tell the whole story. Although pseudo-swap may sound a bit strange at first, it provides several benefits over simply turning swap reservation off. Figure 7-6 illustrates the addition of pseudo-swap to the mix. Figure 7-6. Adding Pseudo-Swap to the Mix
The addition of pseudo swap allows the actual swap space to be reduced to as little as 25 percent of the physical memory. That's not to say that you should reduce it just that you can. If the system is configured with ample physical memory, then there is no danger in reducing the size of the swap map. If, however, memory pressure increases and we don't have actual swap space to handle it, things can get a bit interesting. Consider the following scenarios: First scenario: We have enough physical memory for all the system and user needs. Pseudo-swap is turned on, and device swap is reduced to 25 percent of the available memory. No problem this should work just fine. Second scenario: You have maximized your physical memory, but your processes simply want more! It's easy: configure the amount of swap your processes need. In this scenario, we recommend that you leave pseudo-swap disabled, as you would really prefer to have device swap fulfill the system's paging requirements. Third scenario: Originally we had sufficient memory, turned on pseudo-swap, and reduced the physical swap to a minimum. The challenge is that we have since increased our demand on memory by adding more processes, but we haven't upgraded the memory or the swap space. What happens when we start using the pseudo-swap to satisfy our system needs? When a process starts, its swap space requirements are calculated and reserved. As long as there is device or file system swap space available to cover this reservation, all is fine. Once we exceed the physical swap limit, we begin to allocate from the pseudo-swap area. As swap is reserved for a new region, if it falls within pseudo-swap, then its pages are not reserved; instead they are allocated right form the start. In either case, this has the same net effect on the reservation limit but the dynamics of this region with respect to vhand are quite different. The mechanics of pseudo-swap are that if a swap space cannot be reserved against the available physical swap during the creation of a memory region, then it is flagged as being preallocated in pseudo-swap (this is actually noted in the pregion(s) pointing to the region). On the surface, this almost sounds logical! We need to make room in memory, so we move a page to swap, but if the swap page we move it to is in memory (pseudo-swap), we haven't gained anything we haven't increased the freemem count. This is the case, but the important issue is that swap didn't fail. We just didn't accomplish the desired goal this time, so hopefully vhand will continue and try to steal a page with an actual reserved or allocated back-store page. Once we start allocating from pseudo-swap, in effect the number of pages available for paging out is reduced. If a page is mapped by a region that has been marked as a pseudo-swap region, then all attempts to swap one of its pages simply result in the page remaining where it is. Conceptually, the swap would be successful but at a net-sum-gain of zero as far as increasing the value of freemem is concerned. To avoid wasting vhand's time, regions identified as containing pseudo-swap pages are not eligible for inclusion in the vhand algorithms. When agehand or stealhand points to the pregion of a pseudo-swap region, r_swapmem, it simply moves on to the next pregion in the chain. As pseudo-swap is allocated, it has the effect of reducing the number of physical pages that may be paged out in times of high memory pressure. A process lucky enough to have its pages in pseudo-swap regions will continue to operate with little impact because its pages are, in effect, locked in memory. But those processes resident in the remaining pages will suffer a performance hit because their pages must carry the extra burden of being at risk of being aged and stolen by the paging system. Interpreting the Output of swapinfo If you run the swapinfo command and have pseudo-swap enabled, you will see a line that reports the amount of memory swap available and the amount currently in use. Don't be surprised if pseudo-swap usage is reported even when no physical swap has been allocated. Since pseudo-swap is letting us cheat the limit, the system must be able to adjust this cheat as the kernel takes dynamic pages out of circulation, effectively reducing the available memory count. Therefore, the system reports these kernel-allocated pages as allocated pseudo-swap pages. This effectively reduces the swap reservation limit available and keeps the system from overcommitting its memory resource. Pseudo-swap works well for its intended purpose, but if you push it past the limits, you will have slower overall system performance but everything will still run. Don't be afraid of pseudo-swap, but make sure you understand its purpose. |