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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
