Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>:
> 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?
This starts into some policy but the following is usually used:
1. System applications using shared text have their shared text charged to
the system allocation.
Shared system libraries are charged to the system.
The data space is all charged to the user.
2. User applications using shared text have their shared text charged to
a) the first user attached .... OR
b) the owner of the text (unlikely) OR
c) the charge is divided by the number of attached users and added to
each attached user. If this eventually causes the last user to abort,
then tough - that process gets aborted... OR
d) ignore shared text, it cannot cause an OOM situation.
NOTE: All shared text gets faulted from the program image (I think). This
is equivalent to expanding swap by the size of the program image. It
should be very unlikely that shared text can put a user over the limit.
Therefore it would seem that shared text of any type might be dropped
from the equation for determining OOM contitions...
At least that is my reasoning... I recommend 2d for all shared text.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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:19 EST