Messages in this thread | | | Date | Thu, 16 Mar 2000 13:38:42 +0000 (GMT) | From | James Sutherland <> | Subject | Re: Overcommitable memory?? |
| |
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/
| |