{rtasd,rtc,scanlog}.c schedule_timeout() usage
Nishanth Aravamudan
nacc at us.ibm.com
Tue Dec 21 11:36:27 EST 2004
On Sat, Dec 18, 2004 at 09:41:35AM +0100, Benjamin Herrenschmidt wrote:
> 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.
Also, I just noticed that rtc.c calls rtas_extended_busy_delay_time() to
calculate the time to sleep. It seems that this function takes as parameter an
order value, and calculates a delay of 10^n milliseconds (per the comment). But
then there is another comment claiming to use microseconds as the units. Finally
(regardless of this units issue), the calculated delay is returned and used as
the parameter to schedule_timeout(). This is clearly incorrect logic (even if
correct code currently), though, as it relies on jiffies being the equivalent of
one of these time units. Does anyone know what units this value should have?
Thanks,
Nish
More information about the Linuxppc64-dev
mailing list