On Thu, 16 Mar 2000, Jesse Pollard wrote:
> 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....
It will probably have to be locked in memory, which means keeping it as
small as possible.
> 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...
Not insurmountable.
> > 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.
Yes, we NEED to have Rik's kernel level handler for otherwise terminal
cases - the userspace daemon is intended as a less drastic background
task, simply monitoring free memory and acting if it gets too low - not
handling sudden OOM emergencies, where Rik's code has to save the day.
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:18 EST