The memory-management algorithm tries to keep the size of the free list and the percentage of real memory occupied by persistent-segment pages within specified bounds. These bounds can be altered with the vmtune command, which can only be run by root.
Attention: vmtune is in the samples directory because it is very VMM-implementation dependent. The vmtune code that accompanies each release of AIX was tailored specifically to the VMM in that release. Running the vmtune executable from one release on a different release might well result in an operating-system failure. It is also possible that the functions of vmtune may change from release to release. You should not propagate shell scripts or inittab entries that include vmtune to a new release without checking the vmtune documentation for the new release to make sure that the scripts will still have the desired effect.
The purpose of the free list is to keep track of real-memory page frames released by terminating processes and to supply page frames to requestors immediately, without forcing them to wait for page steals and the accompanying I/O to complete. The minfree limit specifies the free-list size below which page stealing to replenish the free list is to be started. maxfree is the size above which stealing will end.
The objectives in tuning these limits are:
If you have a short list of the programs you want to run fast, you could investigate their memory requirements with svmon (see "Finding Out How Much Memory Is Really Being Used"), and set minfree to the size of the largest. This technique risks being too conservative because not all of the pages that a process uses are acquired in one burst. At the same time, you may be missing dynamic demands that come from programs not on your list that may lower the average size of the free list when your critical programs run.
A less precise but more comprehensive tool for investigating an appropriate size for minfree is vmstat. The following is a portion of the vmstat 1 output obtained while running an XLC compilation on an otherwise idle system. The first line has not been removed--observe that the first line contains summary CPU and other activity measures, but current memory statistics.
procs memory page faults cpu ----- ----------- ------------------------ ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 3085 118 0 0 0 0 0 0 115 2 19 0 0 99 0 0 0 3086 117 0 0 0 0 0 0 119 134 24 1 3 96 0 2 0 3141 55 2 0 6 24 98 0 175 223 60 3 9 54 34 0 1 3254 57 0 0 6 176 814 0 205 219 110 22 14 0 64 0 1 3342 59 0 0 42 104 249 0 163 314 57 43 16 0 42 1 0 3411 78 0 0 49 104 169 0 176 306 51 30 15 0 55 1 0 3528 160 1 0 10 216 487 0 143 387 54 50 22 0 27 1 0 3627 94 0 0 0 72 160 0 148 292 79 57 9 0 34 1 0 3444 327 0 0 0 64 102 0 132 150 41 82 8 0 11 1 0 3505 251 0 0 0 0 0 0 128 189 50 79 11 0 11 1 0 3550 206 0 0 0 0 0 0 124 150 22 94 6 0 0 1 0 3576 180 0 0 0 0 0 0 121 145 30 96 4 0 0 0 1 3654 100 0 0 0 0 0 0 124 145 28 91 8 0 1 1 0 3586 208 0 0 0 40 68 0 123 139 24 91 9 0 0
Because the compiler has not been run recently, the code of the compiler itself has to be read in. All told, the compiler acquires about 2MB in about 6 seconds. On this 32MB system maxfree is 64 and minfree is 56. The compiler almost instantly drives the free list size below minfree, and several seconds of frantic page-stealing activity take place. Some of the steals require that dirty working-segment pages be written to paging space, which shows up in the po column. If the steals cause the writing of dirty permanent-segment pages, that I/O does not appear in the vmstat report (unless you have directed vmstat to report on the I/O activity of the physical volume(s) to which the permanent pages are being written).
This example is not intended to suggest that you set minfree to 500 to accommodate large compiles. It points out how one can use vmstat to identify situations in which the free list has to be replenished while a program is waiting for space. In this case, about 2 seconds were added to the compiler execution time because there weren't enough page frames immediately available. If you observe the page frame consumption of your program, either during initialization or during normal processing, you will soon have an idea of the number page frames that need to be in the free list to keep the program from waiting for memory.
When you determine the appropriate size for the free list for your interactive workload, you can set minfree appropriately with vmtune. maxfree should be greater than minfree by at least 8 (or by maxpgahead, whichever is greater). If we concluded from the example above that minfree needed to be 128, and we had set maxpgahead to 16 to improve sequential performance, we would use the following vmtune command and receive the output shown:
# /usr/lpp/bos/samples/vmtune -f 128 -F 144
minperm maxperm minpgahead maxpgahead minfree maxfree numperm
1392 5734 2 16 56 64 3106
number of memory frames = 8192 number of bad memory pages = 0
maxperm=70.0% of real memory
minperm=17.0% of real memory
minperm maxperm minpgahead maxpgahead minfree maxfree numperm
1392 5734 2 16 128 144 3106
number of memory frames = 8192 number of bad memory pages = 0
maxperm=70.0% of real memory
minperm=17.0% of real memory
AIX takes advantage of the varying requirements for real memory by leaving in memory pages of files that have been read or written. If the file pages are requested again before their page frames are reassigned, this technique saves an I/O operation. (Even if a file page's page frame has been stolen and placed on the free list, if that file page is requested before the page frame is actually used for another purpose, it will be reclaimed from the free list.) These file pages may be from local or remote (for example, NFS) file systems.
The ratio of page frames used for files versus those used for computational (working or program text) segments is loosely controlled by the minperm and maxperm values.
In a particular workload, it may be worthwhile to emphasize the avoidance of file I/O. In another workload, keeping computational segment pages in memory may be more important. To understand what the ratio is in the untuned state, we use the vmtune command with no arguments.
# vmtune minperm maxperm minpgahead maxpgahead minfree maxfree numperm 1433 5734 2 16 128 144 3497 number of memory frames = 8192 number of bad memory pages = 0 maxperm=70.0% of real memory minperm=17.5% of real memory
The default values are calculated by the following algorithm:
minperm (in pages) = ((number of memory frames) - 1024) * .2 maxperm (in pages) = ((number of memory frames) - 1024) * .8
The numperm column gives the number of file pages in memory, 3497. This is 42.7% of real memory. If we know that our workload makes little use of recently read or written files, we may want to constrain the amount of memory used for that purpose. The command:
# vmtune -p 15 -P 40
would set minperm to 15% and maxperm to 40% of real memory. This would ensure that the VMM would steal page frames only from file pages when the ratio of file pages to total memory pages exceeded 40%. On the other hand, if our application frequently references a small set of existing files (especially if those files are in an NFS-mounted file system), we might want to allow more space for local caching of the file pages with:
# vmtune -p 30 -P 60
The schedtune and vmtune commands.