Re: Overcommitable memory??

From: James Sutherland (jas88@cam.ac.uk)
Date: Thu Mar 16 2000 - 10:04:34 EST


On Thu, 16 Mar 2000, Horst von Brand wrote:

> James Sutherland <jas88@cam.ac.uk> said:
>
> [...]
>
> > Except that the process failing is probably NOT the cause of the problem.
> > If your application causes problems on the server, I want it to be YOUR
> > application which dies as a result - not all the other ones!
>
> If you think about it for a moment, it is rarely one process that is the
> root of the problem, it is the set of all processes together that is
> causing it. So, by your own logic, the system should just panic.

No. Typically, one process has blown up for whatever reason (Netscape
seems quite keen on doing this, for example) and swallowed all the RAM it
can get. Killing this process will solve the problem.

Panicking the system is certainly not the right response - better to kill
a handful of processes and keep the system alive.

> [...]
>
> > No, we have GIVEN it 256K of RAM. We don't say "We've got 255Mb of RAM,
> > how much would you like?", the app says "I need 17384Kb of RAM to operate.
> > Can I have it please?". Either the kernel says "yes", and it works, or it
> > says "no", and the app gives up.
>
> And that is the only sensible thing the vast mayority of apps can do, i.e.,
> go down.

We just need to make sure the RIGHT process(es) go down, not just the
"polite" ones which bother checking the memory they are given.

> [...]
>
> > We NEVER allocate memory via malloc() and then later discover we can't
> > honour that allocation - once the memory has been allocated, it is the
> > property of that process, to do with as it pleases.
>
> Never overcommit memory means a few Gb of RAM+spap just in case everybody
> decides to cash in at the same time. I've got much better uses for said
> resources...

Having looked more closely at the code, it looks as if it does overcommit
to a limited extent, usually. This isn't the problem here, though - the
problem is an app with a memory leak. Nothing to do with overcommit, COW
etc. - just too much memory being used.

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/



This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:21 EST