Re: Overcommitable memory??

From: Horst von Brand (vonbrand@pincoya.inf.utfsm.cl)
Date: Wed Mar 15 2000 - 15:10:24 EST


David Whysong <dwhysong@physics.ucsb.edu> said:

[...]

> But that's the wrong thing to do! For example, I start a simulation that
> runs for two months. Then some one starts an app that gobbles memory. My
> long-running simulation malloc's 5 bytes and runs out of memory.

How does the kernel know that this long-running, big memory user isn't a
jed process that went into a loop because the user didn't log out properly
(I've had such around here), while the new, shortlived process is root
trying to log in to kill the hog? There _can_ be no exact rules here, or
they are inmensely complicated, using data which has to be collected for
this purpose. Luckily, they aren't really needed: The system is probably
doomed anyay, killing some processes might just save it, or at least allow
a cleaner shutdown.

What _is_ needed is some way to have propper accounting of resource usage,
this is useful for averting OOM and many other uses. But this is _hard_:
Who do I charge for this new root process (sendmail(8), called by user jrl,
or delivering mail to her)? What about the popd process jrl called up to
retrieve her mail? How do I charge users Jane and Joe Random, which are now
both running Netscape (with it's x-Mb memory usage for the executable alone
(which is shared))? How to charge for the shared libc, bash, ... which
everybody is using? What happens when Jane leaves Netscape, and now Joe is
the sole user, which puts him over his memory usage limit?

-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

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



This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:17 EST