Re: Overcommitable memory??

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Thu Mar 16 2000 - 14:26:15 EST


James Sutherland <jas88@cam.ac.uk>:
> On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
>
> > Den 13-Mar-00 21:28:09 skrev Rik van Riel følgende om "Re: Overcommitable memory??":
> >
> > > Most machines never run out of memory (+swap). That is
> > > the only easy answer. In case something is screwed up
> > > anyway, it's the kernel's job to fix it,
> >
> > Why wouldn't it be much better to delegate this job to a userspace
> > daemon? The advantages I see are
> >
> > - easier customisation of OOM killing rules. Write your own OOM daemon if
> > the existing one isn't satisfactory.
> > - if you don't want OOM killing, simply don't run the daemon.
> > - smaller kernel.
>
> I tend to prefer this as well. A lot of boxes I have used have a similar
> thing for CPU time - after 15 mins, you get reniced, after 60 you get
> killed. Rik's patch would still be useful as a "last line of defence" - if
> the daemon dies from lack of memory, for example, Rik's patch could still
> kill the culprit and allow things to recover.
>
> A nice "clever" daemon could enforce some sort of per-user quota; if any
> user processes go over, say, 100Mb (admin definable) and they get killed;
> if the user goes over, say, 250Mb, their largest processes are killed.
> Then you could warn them if they exceed a "soft" quota. (Perhaps also
> adjust their rlimits accordingly??)

Since you now put the growing process (tables have to be grown to hold
the additional information) what do you do when the daemon itself has to
page into memory and there isn't any available....

This HAS been pointed out several times as the major flaw in the "userspace"
memory control. It will not be reliable. It cannot be trusted to make the
right decision, it will be aborted...

> Essentially, this is what I wanted all along - a nice flexible memory
> "quota" daemon.

What you want is kernel supported resource limits. Nothing more. User space
daemons cannot do this. Now, the limits that are given to the kernel may
be adjusted by a userspace daemon, but only the kernel can catch the OOM
situation. That can occur much faster than context switches caused by
time slice expiration.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
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:18 EST