Re: [PATCH 1/2] mm, oom: introduce oom reaper

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, Dec 17, 2015 at 5:02 AM, Michal Hocko <mhocko@kernel.org> wrote:
> Ups. You are right. I will go with msleep_interruptible(100).

I don't think that's right.

If a signal happens, that loop is now (again) just busy-looping. That
doesn't sound right, although with the maximum limit of 10 attempts,
maybe it's fine - the thing is technically "busylooping", but it will
definitely not busy-loop for very long.

So maybe that code is fine, but I think the signal case might at least
merit a comment?

Also, if you actually do want UNINTERRUPTIBLE (no reaction to signals
at all), but don't want to be seen as being "load" on the system, you
can use TASK_IDLE, which is a combination of TASK_UNINTERRUPTIBLE |
TASK_NOLOAD.

Because if you sleep interruptibly, you do generally need to handle
signals (although that limit count may make it ok in this case).

There's basically three levels:

 - TASK_UNINTERRUPTIBLE: no signal handling at all

 - TASK_KILLABLE: no normal signal handling, but ok to be killed
(needs to check fatal_signal_pending() and exit)

 - TASK_INTERRUPTIBLE: will react to signals

(and then that TASK_IDLE thing that is semantically the same as
uninterruptible, but doesn't count against the load average).

The main use for TASK_KILLABLE is in places where expected semantics
do not allow a EINTR return, but we know that because the process is
about to be killed, we can ignore that, for the simple reason that
nobody will ever *see* the EINTR.

Btw, I think you might want to re-run your test-case after this
change, since the whole "busy loop vs actually sleeping" might just
have changed the result..

              Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>