Messages in this thread | | | Date | Sat, 23 Jul 2005 09:37:53 -0700 | From | Nishanth Aravamudan <> | Subject | Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces |
| |
On 23.07.2005 [13:55:58 +0200], Roman Zippel wrote: > Hi, > > On Sat, 23 Jul 2005, Arjan van de Ven wrote: > > > > What's wrong with using jiffies? > > > > A lot of the (driver) users want a wallclock based timeout. For that, > > miliseconds is a more obvious API with less chance to get the jiffies/HZ > > conversion wrong by the driver writer. > > We have helper functions for that. The point about using jiffies is to > make it _very_ clear, that the timeout is imprecise and for most users > this is sufficient.
We do have helper functions for human-time <-> jiffies (I keep adding new ones :) ). But why not, instead of
set_current_state(TASK_{,UN}INTERRUPTIBLE); schedule_timeout(msecs_to_jiffies(some_constant_msecs));
just have an interface that allows
schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
and push the jiffies conversion to common code?
There are some 300 or so users of schedule_timeout() in 2.6.12. I would say about half are doing something along the lines of
set_current_state(TASK_{,UN}INTERRUPTIBLE); schedule_timeout(HZ/some_constant);
These would be replaced with
schedule_timeout_msecs_{,un}interruptible(1000/some_constant);
I would *not* be changing the callers that do
set_current_state(TASK_{,UN}INTERRUPTIBLE); schedule_timeout(some_other_constant);
even though I think most of these are 2.4 remnants that don't need short, e.g. 1 or 2 timer interrupt, sleeps, but actually can use a 10 or 20 millisecond (HZ=100, 1 or 2 jiffies) sleep.
This emphasizes another advantage of adding these new interfaces, the delay requested does not change with HZ. Internally it does, certainly, but the callers don't need to know that :)
Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |