increasing RAM memory available to a large process--summary

[Guy Harris]

> 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.