Hi Gavin [cc: by mail] !
> The initial allocation done by the VMM is at system boot time and is
> totally independent of what may be stored in memory in the future. This is
> why you need to have your paging space set to at least the size of real
This is not visible in program output (still AIX 4.1):
I have a machine with 128 MB RAM and two paging spaces of 128 MB each,
only one is activated automatically (so page space size == RAM size).
'lsps -a' shows it is used 16 % only (unloadad machine), so it does
not show the space to be allocated from boot.
> To answer your second query, Any real memory not utilised by active
> processes will be used to "buffer" any data and program code read from disk
> (this is why AIX memory utilisation always appears to be at or near 100%).
Quote:> If the demand for "real" memory increases then these memory pages are the
> first to be "stolen" as no "page out" is required (the origional data is
> still available on disk) and can be "paged in" when required.
But this "page in" will AFAIK come from the file system, not paging LV.
Then why should these RAM pages have got allocated page area, if there
is no need to page them out ? (Other than LRU buffer writes to files.)
As the future use of RAM ("buffer", code, or "real program data" like
stack and heap) can not be told at boot time, IMHO there is no use in
allocating paging space for the physical RAM at boot time.
I expect AIX to do that only when processes (or kernel functions)
require address space for stuff without disk backup (= stack + heap +
SHM segments + kernel data like MSQs),
so the system should boot and work with much less paging space than RAM
if large areas serve for code segments and file buffering.
(I currently do not feel like re-configuring my machine with reduced
"hd6" and testing, but AFAIR I had such a configuration on a machine
we had on loan - it had 1 GB RAM and disks of 1 or 2 GB each, and
I think we had a small "hd6" and activated other page spaces in other
VGs only later, so it booted with less paging space than RAM.)
Regards, Joerg Bruehe
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
(speaking only for himself)