lkml.org 
[lkml]   [2000]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcommitable memory??
On Wed, 15 Mar 2000, David Whysong wrote:

> On Mon, 13 Mar 2000, James Sutherland wrote:
> >On Mon, 13 Mar 2000, David Whysong wrote:
> >>
> >> And please explain why my simulation -- that may have started many weeks
> >> (or months) ago -- should "just exit" because some random 5-minute old
> >> Mathematica process went and allocated half a gigabyte of memory?
> >
> >Quite. Ideally, the process will get a SIGTERM first, giving it an
> >opportunity to save and exit safely. If this fails (if, for example, it
> >needs to allocate memory to do so) it will then be SIGKILLed.
>
> 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.

So under the OLD behaviour, your app collapses in a heap (excuse pun).

> Why should I be penalized for somebody else's problem? SIGKILL the
> offending app, not some large but otherwise well-behaved and valuable
> process.

This is precisely what the NEW behaviour does - kill the newly started
memory hog. Your simulation then gets the 5 bytes it asked for, albeit
after a slight delay.

> >This will be rather difficult to implement, but ultimately the scenario I
> >would like is:
> >App 1 fails to allocate memory - OOM handler triggered.
> >* Hook at this point to bring in additional swap space?
>
> Pointless. This just delays the inevitable. Why not just mount all your
> swap in the first place? If you have more, then you aren't really OOM.

The swap may not even exist previously - it could be a shared "emergency"
swap space over NFS, or it could be free space on a local disk. You
wouldn't want to use this as swap normally, but can temporarily bring it
online.

> >OOM handler selects several processes to terminate to free up VM.
>
> Why several? You're more likely to kill "innocent" processes.

Just one, then a second if the problem remains.

> [SNIP rest of far too complicated plan to handle OOM situations...]
>
> >I should point out, though, that from the very beginning of this scenario,
> >we are looking at a fairly hosed machine with dying processes. We may be
> >able to recover by bringing additional swapspace online
>
> So you fix an OOM condition by dynamically adding memory? That seems
> backwards. If you had extra swap, why not use it in the first place.

You may well have perfectly valid reasons for not using it initially. It
could, for example, be a shared scratch area on a server. If all the
machines had (idle) swap files on that partition, it would waste all the
space - and the one machine needing it would get very little.

Equally, you don't want all your free disk space committed to a swap file
on the offchance it might come in handy!

> >and/or killing suspect processes, but urgent attention is needed.
>
> The only possibilities are to (a) enforce hard memory limits with no
> overcommit, thereby wasting large amounts of swap space that will never
> get used while not really solving the problem,

As well as *destroying* performance (you'd effectively eliminate COW
capability on fork - if your 500Mb simulation wants to fork a 100k mailer
process to send you an update, the kernel has to allocate and copy 500Mb
of RAM/swap first, then discard it all again.)

> or (b) killing the offending process(es). Rik's approach seems to be a
> good implementation of (b); in fact, I am starting to believe that his
> general approach (and I say nothing about his implementation here) is
> the ONLY reasonable way to deal with OOM situations.

I agree. No doubt the selection algorithm for the "hit list" could be
fine-tuned, but it's a very big improvement as it stands.


James.


-
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    [from the cache]
©2003-2011 Jasper Spaans