Messages in this thread | | | Date | Mon, 7 Aug 2000 20:26:40 -0700 | From | David Gould <> | Subject | Re: RFC: design for new VM |
| |
On Mon, Aug 07, 2000 at 10:40:52AM -0700, Gerrit.Huizenga@us.ibm.com wrote: ... > ... Another mechanism, > and the one that we chose in our operating system, was to use a modified > process resident set sizes as the machanism for page management. The > basic modifications are to make the RSS tuneable system wide as well > as per process. The RSS size "flexes" based on available memory and > a processes page fault frequency (PFF). Frequent page faults force the > RSS to increase, infrequent page faults cause a processes resident size > to shrink. When memory pressure mounts, the running process manages > itself a little more agressively; processes which have "flexed" > their resident set size beyond their system or per process recommended > maxima are among the first to lose pages. And, when pressure can not > be addressed to RSS management, swapping starts.
Hmmm, the vm discussion and the lack of good documentation on vm systems has sent me back to reread my old "VMS Internals and Data Structures" book, at least for historical perspective. The above description of per process RSS size adjustment controlled by page fault rate sounds quite similar to the scheme in VMS.
Basically in VMS, processes page against themselves, not against the system as a whole. A process grows or shrinks based on its recent pagefault rate which is configurable with upper and lower targets. This happens more or less continously. In addition the system has global goals for free and dirty pages and in response to memory pressure will start cleaning pages, (via a page writer task), or if need be, stealing pages from processes or even swapping whole processes (via swapper task).
I am probably making a hash of decribing this, and of course VMS is not the last word by any means, but the system was very tunable, and had specific explicit mechanisms to attain many of the goals of vm system. As such it is an instructive example if only to point out the problems to be solved, and at least one way to solve them. If you wish a real description there is always the "big black book" by Kennah and Bates (IIRC), which has about 150 pages just on the vm. For a short summary, I found a couple of web pages about the t:
http://cctr.umkc.edu/vms/72final/6491/6491pro_002.html#memory_chap http://cctr.umkc.edu/vms/72final/6491/6491pro_003.html
I hope someone finds this useful...
-dg
-- David Gould dg@suse.com SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380 "I sense a disturbance in the source" -- Alan Cox
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |