Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces

[Nishanth Aravamudan <nacc@us.ibm.com>]

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