32 kHz timer granularity when CONFIG_NO_HZ is enabled

Hi,

I have OMAP 3 and I'm using the 32 kHz timer, CONFIG_OMAP_32K_TIMER_HZ is set to 128 and CONFIG_NO_HZ is enabled. Many OMAP-based boards in arch/arm/config seem to have this kind of default configuration.

This has the effect that for example msleep(1) sleeps much longer than intended, between 7,8 and 15,6 ms, for no apparent good reason.

I'm just wondering whether all this is intentional. :-)

Sakari Ailus
[email protected]

1000 ms/sec / 128 HZ/sec == 7.8 ms/HZ

The "good reason" is that msleep() takes at least one HZ, since it's based on the scheduler's use of jiffies.

A patch to make msleep() use hrtimers didn't fly; the change in semantics could make trouble, despite the acknowledged problems of using jiffies instead of wall clock time.

I can think of several semantic variants of msleep that might be wanted:

msleep_deferrable() ... still HZ based, but ok to defer
the tick for IRQ reduction
msleep_exact() ... uses hrtimers, almost certainly
costs an IRQ (unless HIGH_RES_TIMERS is off)
msleep_fuzzy() ... current semantics, units of jiffies
but not deferrable

Folk seem mostly content with fuzzy() for now, although there are certainly folk who'd rather have exact(). And the slowdown of an msleep(1) is probably the canonical example of why exact() would collect users.

- Dave