Re: [RFC] Dynamic Tick and Deferrable Timer Support
From: Jon Hunter
Date: Fri Jan 30 2009 - 14:04:47 EST
john stultz wrote:
As an aside, there are some further hardware limitations in the
timekeeping core that limit the amount of time the hardware can sleep.
For instance, the acpi_pm clocksource wraps every 2.5 seconds or so,
so we have to wake up periodically to sample it to avoid wrapping
Just to be able to deal with all the different hardware out there, the
timekeeping core expects to wake up twice a second to do this
sampling. It may be possible to push this out if you are using other
clocksources (HPET/TSC), but if sleeps for longer then a second are a
needed feature, we probably will need some infrastructure in the
timekeeping core that can be queried to make sure its safe.
The variable "max_delta_ns" is used by the dynamic tick to govern the
maximum time a given device can sleep. Hence, this variable should be
configured as necessary for the device you are using. Therefore, if your
device has a timer that will wrap every 2.5 seconds, then for this
device the "max_delta_ns" should be configure so that it does not exceed
So what I was proposing is that for devices that have timers that would
allow you to sleep beyond ~2.15 seconds (current max imposed by the
clockevent_delta2ns function), why not increase the dynamic range (make
this a 64-bit variable) or base (ie. from nanoseconds to milliseconds)
to permit longer sleep times for devices that can support them? This
should not have any negative impact on devices that cannot support such
long sleep times.
So far I have not encountered any issues with doing this. Let me know if
this does or does not address your concerns.
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/