Messages in this thread | | | Date | Thu, 17 Dec 2015 11:55:11 -0800 | Subject | Re: [PATCH 1/2] mm, oom: introduce oom reaper | From | Linus Torvalds <> |
| |
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
| |