virtual memory 4496
Jan VorbrYggen
Yeah. The problem on the VAX was that the WS list was an array sized by WSMAX parameter that resided inside the process header, and the system had an array of resident process headers (the balance set). Since system space was limited, if you tried to increase WSMAX larger, you were forced to drop the balance set count.
I never had that ... dating back to my original implementations in the 60s. working set size was mechanism for limiting over commit of real storage...
Also because all processes had the same sized WS array, it could cause waste. If you set the value WSMAX high to handle one or two very large processes (like a database server), all the zillions of normal tiny processes would have these large pinned down ws list that they didn't need. If you set the value smaller, then the large process would soft-fault a lot.
Bill Todd I found such studies, which appear to show that VMS's mechanism is within, by looking at a graph, about 0.5% of LRU. This was a unpleasant woman to track down because...
The HP documentation does state that the WS list has moved out of the process header to S2 space as of OS version 7.3-2 (I don't know what year that was).
But (and correct me if I am wrong, I haven't touched VMS since 1994) the working set still seems to be managed as a great whacking one-size-fits-all vector of working set entries sized by WSMAX that must reside in non-pagable memory (or at least I saw nothing that implied a change in their basic approach).
WRT WinNT, I have never found any documentation on it as detailed as the VMS internals guide so its internal operations are just a guess. However its KPROCESS header data structure contains a linked list field called WorkingSetExpansionLinks which leads me to guess it uses a more flexible approach.
Eric
Alt Folklore Computers from Newsgroups