Re: User space out of memory approach

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Jan 27, 2005 at 02:54:13PM -0400, Mauricio Lin wrote:
> Hi Andrea,
> 
> On Wed, 26 Jan 2005 01:49:01 +0100, Andrea Arcangeli <andrea@suse.de> wrote:
> > On Tue, Jan 25, 2005 at 08:11:19PM -0400, Mauricio Lin wrote:
> > > Sometimes the first application to be killed is XFree. AFAIK the
> > 
> > This makes more sense now. You need somebody trapping sigterm in order
> > to lockup and X sure traps it to recover the text console.
> > 
> > Can you replace this:
> > 
> >         if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
> >                 force_sig(SIGTERM, p);
> >         } else {
> >                 force_sig(SIGKILL, p);
> >         }
> > 
> > with this?
> > 
> >         force_sig(SIGKILL, p);
> > 
> > in mm/oom_kill.c.
> 
> Nice. Your suggestion made the error goes away.
> 
> We are still testing in order to compare between your OOM Killer and
> Original OOM Killer.

Ok, thanks for the confirmation. So my theory was right.

Basically we've to make this patch, now that you already edited the
code, can you diff and send a patch that will be the 6/5 in the serie?

(then after fixing this last very longstanding [now deadlock prone too]
bug, we can think how to make at a 7/5 that will wait a few seconds
after sending a sigterm, to fallback into a sigkill, that shouldn't be
difficult, but the above 6/5 will already make the code correct)

Note, if you add swap it'll workaround it too since then the memhog will
be allowed to grow to a larger rss than X. With 128m of ram and no swap,
X is one of the biggest with xshm involved from some client app
allocating lots of pictures. I could never notice since I always tested
it either with swap or on higher mem systems and my test box runs
with an idle X too which isn't that big ;).