bruce@central.sun.com (Bruce Samuelson) (08/24/89)
In Sunspots 8.89, I asked whether it is possible to "make more RAM memory available to a memory-intensive process than Unix is willing to dole out, in order to reduce its virtual memory paging." I received one direct response from Jordan Hayes (uunet!Morgan.COM!jordan). We also discussed reducing disk fragmentation. Regarding allocating more physical memory to a process, Jordan said it is not possible: That's because the Unix paging strategy is to start paging (i.e., using virtual memory) when you've used up something like 2/3 of available memory, so that the degradation is smooth. There's nothing you can do except buy more memory or get a faster disk (so that paging isn't such a big performance penalty) ... further, real memory gets fragmented, so finding large chunks to give programs gets harder and harder ... rebooting will help you for a while (if the first thing you do is start your application), but in general you'll see about 2Mb out of 4Mb (after the kernel) and about 4.5 out of 8Mb. I exchanged further messages with him, with me wishing that Unix offered some ways for users to tune its memory allocation strategy to the details of their workload, and him saying that the strategy employed by SunOS is the result of years of work and that "messing with it almost uniformly brings disasterous results." He did offer the following possible solution: My request: I'd like to lock a couple megabytes of my large process into memory so it can't get paged out. 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. I complained that Unix was tuned to a timesharing machine with many users, while on workstations it should be tuned to a single user environment. He countered: "4.3BSD, which runs mostly on Vaxes in a timesharing environment has a vastly different virtual memory subsystem that SunOS 4.0 does, which is used mainly in the manner that you describe." We also discussed fragmentation in the BSD fast file system. He cited three references in considerable detail (one being the Karels / McKusick / Leffler / Quarterman book "The design and implementation of 4.3BSD") explaining how the file system minimizes fragmentation. One constraint is that if you try to cluster a file or related files on a cylinder group, you could end up displacing files from this group to other non local groups, degrading their localization. Our correspondence ended with me wistfully suggesting that Unix and the SunOS could still do better on memory allocation and disk fragmentation: 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. 2) The cpu spends most of its time in an idle loop. Why not use this time constructively to reduce memory fragmentation? Disk fragmentation: I had no suggestions for improving this for disks that are busy all the time, but for ones that have a lot of idle time, there must be some way to use it to improve fragmentation statistics. Roger Boyle recently posted a message to Sun-Managers which also noted that "according to 'ps', not all physical memory seemed to be in use". However, "A call to Sun elicited the response that under V4 of the OS (which we run), 'ps' and 'vmdisp' were likely to provide very inaccurate figures (while under V3 they did not), and that this was the cause of the problem."
guy@uunet.uu.net (Guy Harris) (09/28/89)
> 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.