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??)
Essentially, this is what I wanted all along - a nice flexible memory
"quota" daemon.
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:17 EST