On Thu, Dec 17, 2015 at 5:02 AM, Michal Hocko <mhocko@xxxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>