{rtasd,rtc,scanlog}.c schedule_timeout() usage

Benjamin Herrenschmidt benh at kernel.crashing.org
Sat Dec 18 19:41:35 EST 2004

On Fri, 2004-12-17 at 16:54 -0800, Nishanth Aravamudan wrote:
> Hi,
> I'm trying to work some more on auditing the usage of schedule_timeout(),
> replacing most calls with either msleep() or msleep_interruptible(), depending
> on the state to sleep in. I am now begginning to replace code outside of drivers
> and came across arch/ppc64/kernel/{rtc,rtasd,scanlog}.c, all of which use
> TASK_INTERRUPTIBLE schedule_timeout() calls.
> My understand, though, is that TASK_INTERRUPTIBLE directly indicates that one
> should be able to handle waking up early if a signal is received. I don't see
> any signal handling / responding in the code around these timeouts. Would
> TASK_UNINTERRUPTIBLE work in these cases (indicating sleeping for waitqueue
> events (which I don't see around the code, so I'm guessing means an absolute
> sleep). If the latter, then perhaps I can use msleep_interruptible(). If you
> only wish to sleep until a signal is received (or the timeout occurs) then
> msleep_interruptible() may be a valid choice.
> Please let me know what you think.

>From my experience, there's also a side effect of using UNINTERRUPTIBLE,
which is that your sleep time gets counted as load in the loadavg. In
the case of a kernel thread that don't do signals and need to pop up
regulary, it's best to use INTERRUPTIBLE after making sure all signals
are blocked.


More information about the Linuxppc64-dev mailing list