Re: [PATCH] msleep() with hrtimers

[Roman Zippel]

Hi,

On Sat, 4 Aug 2007, Arjan van de Ven wrote:

> > hr_msleep makes no sense. Why should we tie this interface to millisecond 
> > resolution?
> 
> because a lot of parts of the kernel think and work in milliseconds,
> it's logical and USEFUL to at least provide an interface that works on
> milliseconds.

If the millisecond resolution is enough for these users, that means the 
current msleep will work fine for them.

> > Your suggested msleep_approx makes not much sense to me either, since 
> > neither interface guarantees anything and may "approximate" the sleep 
> > (and if the user is surprised by that something else already went wrong).
> 
> an interface should try to map to the implementation that provides the
> best implementation quality of the requested thing in general. That's
> the hrtimers based msleep().

This generalization is simply not true. First it requires the 
HIGH_RES_TIMERS option to be enabled to really make a real difference. 
Second a hrtimers based msleep has a higher setup cost, which can't be 
completely ignored. "Best" is a subjective term here and can't be that 
easily generalized to all current users.

> > If you don't like the hrsleep name, we can also call it nanosleep and so 
> > match what we already do for userspace.
> 
> having a nanosleep *in addition* to msleep (or maybe nsleep() and
> usleep() to have consistent naming) sounds reasonable to me.

We only need one sleep implementation of both and msleep is a fine name 
for the current implementation - not only does it describe the unit, but 
it also describe the best resolution one can expect from it.

> Do you have something against hrtimer use in general? From your emails
> on this msleep topic it sort of seems you do.... 

I can give the question back, what do you have against simple timers, that 
you want to make them as awkward as possible to use?
hrtimer have a higher usage cost depending on the clock source, so simply 
using them only because they are the new cool kid in town doesn't make 
sense. It may not be that critical for a simple sleep implementation, but 
that only means we should keep the API as simple as possible, that means 
one low resolution, cheap msleep and one high resolution nanosleep is 
enough. Why do you insist on making more complex than necessary?

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/