Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: auspex!guy@uunet.uu.net (Guy Harris) Newsgroups: comp.sys.sun Subject: Re: increasing RAM memory available to a large process--summary Keywords: SunOS Message-ID: <1772@brazos.Rice.edu> Date: 28 Sep 89 02:05:01 GMT Sender: root@rice.edu Organization: Sun-Spots Lines: 56 Approved: Sun-Spots@rice.edu X-Sun-Spots-Digest: Volume 8, Issue 142, message 3 of 5 > further, real memory gets fragmented, so finding large chunks to give > programs gets harder and harder ... Eh? Fragmented by what? You don't give "large chunks" to programs, you give pages to programs, and pages are all the same size, at least on Suns (and on lots of other machines and OSes). Physical memory is also consumed by various kernel data structures, but they're taken from another pool of pages, which again gets pages given to it. It's not as if you have little fragments scattered throughout physical memory, breaking up pages so you can't give them to programs. > His solution: You can do this in SunOS (and probably Ultrix) -- try making > your data area a shared piece of memory -- then it has to stay in main > memory since multiple process are now potentially depending on it, and > would croak if it got swapped out. Works great in 3.x. Doesn't work worth a damn in 4.x. I can't speak for Ultrix, but I would certainly not simply assume that, say, S5 shared memory segments are wired down there. The "it has to stay in main memory since multiple processes are now potentially depending on it, and would croak if it got swapped out" is complete nonsense. Processes don't croak if they touch a page that's not in memory, they cause a page fault that causes the VM code to pull the page in. This applies to shared code pages, System V shared memory, pages shared as a result of "mmap", and unshared pages. The only reason S5 shared memory segments were locked into memory in SunOS 3.x (x >= 2; it wasn't available before then) is that the old Berkeley VM system didn't make it convenient to add shared memory, and the quick and easy solution was to wire them down. The SunOS 4.x VM system makes it convenient, and they're not wired down. SunOS 4.1 may have a mechanism for wiring down pages. It will, of course, be a privileged operation. > Memory allocation: 1) The user knows what programs he will run and should > be allowed more control over memory and cpu resource allocation. I cited > realtime systems, and to some extent OS/2, as operating systems where this > can be done. It might be nice, but even single-user machines can end up being multi-user - unless you trust people who log into your machine, or don't let other people log into it, you don't necessarily want control of that sort to be granted by non-privileged operations. It might be a good idea to allow a user to say "nobody I don't trust will be allowed to run processes on this machine, so I'll make controls like that non-privileged", or give the "owner" of the machine the privilege to use those controls, but that might not be sufficiently secure in other environments, and might also give the user the chance to well and truly screw up their machine's configuration. > 2) The cpu spends most of its time in an idle loop. Why not > use this time constructively to reduce memory fragmentation? Because there's no fragmentation to reduce, as explained above.