Linda Walsh <law@sgi.com> said:
> John Ripley wrote:
> > The whole point is: in a system without overcommit, a process is never
> > killed for overcommitting.
> ---
> Exactly. *Deciding* what processes to kill is an administrative
> *policy*. It shouldn't be an automatic kernel function except as an
> extension.
Too bad there is no simple way to describe a reasonable policy, and just
stopping everything in its tracks 'til the sysadmin shows up isn't an option.
> I feel safer running an application on a system that I know will
> either deny resources that aren't present or suspend a process that can't
> be given a denial. Then I know what is happening in my "state machine".
Suspending processes only makes the problem much worse...
[...]
> What other system calls/functions overcommit?
The kernel does vmalloc() and kmalloc() and such internally, page tables
use space, then there are buffers and caches of several clases. Just
receiving network traffic uses up RAM, handling routes, IP addresses and
ARP ditto, ... If you use many file descriptors, this uses RAM too. Sure,
you can clamp all of them down, but you won't be able to come up with a
one-size-fits-all solution. A personal workstation is quite different than
a fileserver, a webserver, a router or a firewall.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- 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 : Fri Mar 31 2000 - 21:00:19 EST