Maybe, but this was a slight misunderstanding: i was NOT suggesting to set it to 1, i was just mentioning it as an influence towards how the kernel is using and allocating memory.

You might want to read more about how this works by searching for "least recently used [daemon]". This is what "lru" and "lrud" respectively stand for.

"lruable" and "pinned" are two different things: "pinned" means it cannot get swapped out. AIX was, for the longest time, using a "early swap allocation" attitude towards using swap space. As soon as a process started the memory it might need in swap once it might get swapped out completely was calculated and this much amount of swap was allocated immediately. This is why some software manufacturers still insist on swap space being "two (or even three!) times the size of the memory plus 512MB" or similar. A 4.3.3 system with 70% swap used was not necessarily choking at all, but could well be perfectly sized and tuned.

Beginning with 5.0 and 5.1 this was changed to a "late swap allocation" strategy. Swap is now only allocated if swpping really takes place (like it has been under SunOS before).

"lru" on the other hand, means the following: The kernel knows "computational memory" (memory given to programs) and "file memory" (=cache). The "lrud" scans all these pages and - if necessary - tries to "steal" from one to give to the other. What exactly constitutes "necessity" in this case is parameterized by the said values of maxperm, minperm, maxclient, minclient and numperm. How the lrud does this is set by the "lru_file_repage" parameter. You might want to read this article by Jaqui Lynch for more info. Stealing from computational pages may well cause paging operations, so there is some connection between the two areas, but they are not the same at all.

See above: file memory is (simplistically put) otherwise unused memory used to cache I/O operations (aka "disk cache"), nothing else. I have not used the tool you use so it is difficult for me to interpret its output, but what i told you is in accordance with IBM literature, so i suppose it is as correct as it can be.

I hope this helps.

bakunin