Re: [PATCH] oom_pardon, aka don't kill my xlock

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Tue, Sep 28, 2004 at 03:33:52PM +0200, Herbert Poetzl wrote:
> On Mon, Sep 27, 2004 at 01:42:19PM -0300, Marcelo Tosatti wrote:
> > On Mon, Sep 27, 2004 at 07:12:53PM +0200, Herbert Poetzl wrote:
> > > On Mon, Sep 27, 2004 at 10:35:54AM -0300, Marcelo Tosatti wrote:
> > > > On Mon, Sep 27, 2004 at 02:12:26PM +0100, Jon Masters wrote:
> > > > > Hi all,
> > > > > 
> > > > > Just out of interest then...suppose we've got a loopback swap device
> > > > > and that we can extend this by creating a new file or extending
> > > > > somehow the existing one.
> > > > > 
> > > > > What would be wrong with having the page reclaim algorithms use one of
> > > > > the low memory watermarks as a trigger to call in to userspace to
> > > > > extend the swap available if possible? This is probably what Microsoft
> > > > > et al do with their "Windows is extending your virtual memory, yada
> > > > > yada blah blah". Comments? Already done?
> > > > 
> > > > You dont to change kernel code for that - make a script to monitor 
> > > > swap usage, as soon as it gets below a given watermark, you swapon 
> > > > whatever swapfile you want.
> > > 
> > > hmm, sounds good, but what if next 'burst' of
> > > swapped out data is larger than the watermark?
> > 
> > Give the watermark a large enough value.
> 
> right, probably setting it to the currently 
> available swapspace solves that issue ;)
> 
> anyway as I said, I'm fine with 'does not
> work' but not very happy with half-assed
> userspace solutions ...

Herbert,

Honestly, I dont see much difference makes if the swapon procedure
is called from within the kernel instead from userspace.

Have you actually tried such a "on demand swapon" entirely
from userspace to call it "half-assed" solution ? :)

The act of killing tasks is controversial and always generates
debates here. I bet we will continue seeing them over
the years.

If one dont want the OOM killing to happen, he should correctly setup the 
swap size for his workload (or have a "on demand swapon" solution which 
can be implemented in userspace), or unset overcommit mode. 

There's not much to argue about that.

One controversial issue is the OOM killer policy, which is
hardcoded into the kernel - through the last years there have
been several attempts to make it selectable (which this "oom_pardon" 
patch is about). 

None of these attempts have made into the mainline kernel, because there
hasn't been an agreement on what is the best implementation 
of such feature - each implementation is specific to one user 
group need (for example "dont kill tasks named bla" or "dont kill
tasks from UID bla" or, or).

But other than the OOM killer policy selection or tuning there's not much
to be argued really.