32 kHz timer granularity when CONFIG_NO_HZ is enabled

32 kHz timer granularity when CONFIG_NO_HZ is enabled

[Sakari Ailus]

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
sakari.ailus@nokia.com

Re: 32 kHz timer granularity when CONFIG_NO_HZ is enabled

[David Brownell]

On Wednesday 22 October 2008, Sakari Ailus wrote:
> 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.

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.


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

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