Gripe about mickey-mouse VM behaviour on many Unixes

[Larry McVoy]

In article <19821 at watdragon.waterloo.edu> tbray at watsol.waterloo.edu (Tim Bray) writes:
>1. On a 32-Mb (4.3bsd) machine with *nothing* else happening, the OS stupidly 
>   pages away at you if you try to use more than about 20 Mb in the inane 
>   belief that the memory will be needed any moment for one of those gettys or
>   nfsds or something that aren't doing anything.

Not a great alg but not terrible if you are running a time sharing system.
Take your 32 meg, chop of the ~2 meg for the kernel, chop off the ~4 meg
for the buffer cache, and you have about 26 meg left.  Now there is still 
something fishy here - if I've got the numbers right, it does seem odd that
the pager is beating you up with 6 megs free.  I don't believe this for a
second.  Try this

$ adb /vmunix /dev/kmem
lotsfree/D
freemem/D
^D

The pager does not turn on until freemem < lotsfree (and lotsfree on Sun's
is typically small, like 256K or so).  So something is wacko.

>2. A process using only a moderate amount of memory (you think) runs like
>   a dog, and you note that the system is spending much of its time in
>   system state or idle.  Why, you wonder.  It quickly becomes apparent 
>   that the information produced by items such as ps, vmstat, vsar, top, 
>   and so on, is comparable in relevance and accuracy to Robert Ludlum novels 
>   or peyote visions.  (SunOS the villain here).

Yeah, well, um, yeah.  Right. Well, it's like this see...  Actually, the real
problem is sharing.  Who do you charge shared libraries to?  The numbers
displayed by all those programs don't take that into account, but they should
give you a general idea.  Oh, yeah, I assume 4.0 or greater, things were
easy before then.

>3. On a 64-Mb (MIPS) machine, your paging rate, system time, and idle time 
>   all go through the roof if your process insolently tries to random-access
>   more than 32 Mb of memory at once.

Waddya expect?  :-) :-)

>Look, we all appreciate the tender loving care that VM architects have put
>into strategies that are friendly to 100+ moderate-size processes context
>switching rapidly in time-sharing mode.  But there are other ways to use
>computers, and they are currently very poorly supported.  We paid for that
>memory, we have a good use for it, and the OS is getting in our way, and it's
>also REFUSING TO TELL US ACCURATELY WHAT'S GOING ON - an unforgiveable sin by
>my Unix dogma.

Hmm.  The SunOS VM model was designed with exactly this in mind.  You can
use damn near 100% of physical mem on a 4.0 or greater rev of the OS (the
os uses some, but on a 32 meg machine you should be looking at close to
30 megs of user usable ram).

At any rate, qwitchyerbitchin and tell me what you want to have happen.
Don't forget that your solution has to work well when I'm time sharing,
when one process wants the whole machine, and when two processes want the
whole machine.  And if you get it right, I'll get it into SunOS or die
trying.  Looking forward to your reply,
---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.
    Besides, I frequently read news when I'm drjhgunghc, err, um, drunk.
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm at sun.com