Messages in this thread |  | | | Date | Wed, 15 Mar 2000 10:49:45 +0000 (GMT) | | From | James Sutherland <> | | Subject | Re: 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/
|  |