Re: [PATCH] msleep() with hrtimers

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.

except that you get a 20ms minimum, and 10ms increment.

This generalization is simply not true. First it requires the
HIGH_RES_TIMERS option to be enabled to really make a real difference.

so? you provide the best possible for the config options selected...


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.

that's... combining 2 independent things into one. That's not a really
good idea.


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?

msleep() isn't about timers. The timer type used is an implementation
detail behind the interface!!!!

Timers are course resolution that is highly HZ-value dependent. For
cases where you want a finer resolution, the kernel now has a way to
provide that functionality... so why not use the quality of service this
provides..

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.

no but they DO provide a much better quality of the api implementation;
instead of a 20ms timeout you get really close to what you asked for!

There have been drivers that did if (HZ<1000) mdelay(x); else msleep(x);
Yes that's horrible, but it's a clear sign that this matters.

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?

ehm it was you who insisted on adding complexity to this; the initial
proposal was to just replace the msleep() implementation with one that
has a more gentle behavior (you ask for 1ms you get 1ms, not 20ms)

What really is your problem with that? "It may be more expensive on some
hardware?"

--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

-
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/

Relevant Pages

  • Re: [PATCH] msleep() with hrtimers
    ... because a lot of parts of the kernel think and work in milliseconds, ... If the millisecond resolution is enough for these users, ... Second a hrtimers based msleep has a higher setup cost, ...
    (Linux-Kernel)
  • [patch 16/43] ktimer documentation
    ... +ktimers - subsystem for high-precision kernel timers ... +This patch introduces a new subsystem for high-precision kernel timers. ... +resolution and low precision use cases - once the precision-sensitive ...
    (Linux-Kernel)
  • High resolution timers on AT91SAM926x
    ... Is there a way to enable high resolution timers on AT91SAM926x? ... best resolution I can get (kernel 2.6.23.11-rt14 with at91 patch from ...
    (Linux-Kernel)
  • Re: Real time clock with millisecond resolution
    ... Please forgive me for my newbie question. ... time to be in millisecond resolution. ... system time to get a high resolution calendar time. ...
    (microsoft.public.vc.language)
  • Re: [patch 00/21] hrtimer - High-resolution timer subsystem
    ... OTOH if the hardware allows it, both clocks can do the same thing, but I really would like to have the possibility to give higher resolution only to those asking for it. ... Given that only a very small number of applications really need the extra resolution, I think it makes a lot of sense that those applications incur the overhead and others, which don't need nor want the higher resolution, just use the old low resolution timers. ... On the complexity thing, your new organization makes the added "complexity" rather non-complex, in fact, you might say it is down right simple, for which, thank you. ...
    (Linux-Kernel)