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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On 23.07.2005 [22:12:30 +0200], Roman Zippel wrote:
> Hi,
> 
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> 
> > > Jiffies are the basic time unit for kernel timers, hiding that fact gives 
> > > users only wrong expectations about them.
> > 
> > We already have msleep() and msleep_interruptible(), which hide jiffies
> > in milliseconds. These interfaces are their parallel in the wait-queue
> > case. If you don't want to use them, or their use is not appropriate,
> > then the callers won't be changed.
> 
> I'm not exactly impressed with their implementation, it's completely silly 
> that there is no such convience function based on jiffies, e.g. if you 
> look at the msleep_interruptible(), you'll find quite a few 
> "msleep_interruptible(jiffies_to_msecs())".

Patches are welcome, I guess :)

> msleep_interruptible() is especially bad as there are a few users who 
> check the return value and since it adds one to the timeout, you can 
> create loops which may never timeout (as e.g. in drivers/w1/w1_therm.c: 
> w1_therm_read_bin()), this is nice example of a bad interface.
> 
> These two function should actually look like this:
> 
> static inline void msleep(unsigned int msecs)
> {
> 	sleep(msecs_to_jiffies(msecs));
> }
> 
> static inline int msleep_interruptible(unsigned int msecs)
> {   
> 	sleep_interruptible(msecs_to_jiffies(msecs)) != 0;
> }

Where are sleep() and sleep_interruptible() defined? And this basically
pushes down the identical implementation a layer, correct? Finally, you
cannot simply do msecs_to_jiffies() in the caller of
sleep{,_interruptible()}, unless sleep{,_interruptible()} add 1 to every
request themselves. The basic issue is that with jiffies and ticks being
identical, there is no concept of the inter-tick position (i.e., a
sub-jiffy value), and the callers of these conversion functions *must*
assume they are going to be added to the timer subsystem immediately
before a timer interrupt occurs. An entire tick has not elapsed, but if
the caller had not added 1, then we could potentially go off almost an
entire tick early. The +1 is basically specifying we are asking to add
our delay to the *next* tick.

> > My goal is to distinguish between these cases in sleeping-logic:
> > 
> > 1) tick-oriented
> > 	use schedule_timeout(), add_timer(), etc.
> > 
> > 2) time-oriented
> > 	use schedule_timeout_msecs()
> 
> There is _no_ difference, the scheduler is based on ticks. Even if we soon 
> have different time sources, the scheduler will continue to measure the 
> time in ticks and for a simple reason - portability. Jiffies _are_ simple, 
> don't throw that away.

I agree that from an internal perspective there is no difference, but
from an *interface* perspective they are hugely different, simply on the
basis that one uses human-time units and one does not.

I guess we must continue to agree to disagree.

I am still waiting for some feedback from Andrew if he would prefer a
jiffy-only version or both the jiffy and msec version.

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/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux