lkml.org 
[lkml]   [2000]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Avoiding OOM on overcommit...?
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.372 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site