Messages in this thread | | | Date | Tue, 20 Mar 2012 21:58:57 -0700 | From | John Stultz <> | Subject | Re: Not able to use HIGH_RES_TIMERS on ARM |
| |
On 03/19/2012 06:26 AM, Russell King - ARM Linux wrote: > On Mon, Mar 19, 2012 at 06:49:34PM +0530, Ajeet Yadav wrote: >> Therefore our target configuration with 2.6 kernel was >> GENERIC_CLOCKEVENTS=y, ARCH_USES_GETTIMEOFFSET=y, > It's absolutely absurd to have a platform converted to use clockevents > and clocksources, and then select ARCH_USES_GETTIMEOFFSET. That's saying > "I provide the new infrastructure, but I want the dodgy old compatibility > which doesn't work properly with a set of other features as well". > >> I conclude that GENERIC_CLOCKEVENTS is supported, hence I must set >> ARCH_USES_GETTIMEOFFSET=n, in order to use NO_HZ, HIGH_RES_TIMERS, >> IRQSOFF_TRACER, PREEMPT_TRACER > Correct. If you're using clockevents and clocksources, you should not > select ARCH_USES_GETTIMEOFFSET. >
Hey Ajeet, As Russell pointed out, it looks like you're confused as to the use of ARCH_USES_GETTIMEOFFSET. That option is only for legacy systems that don't provide continuous clocksources that can be used for timekeeping.
In the past, time was incremented by one tick every timer interrupt. Some systems could use the timer hardware (usually PIT style decrementer) to calculate inter-tick times. Its only for this style of hardware, that either wraps or resets each tick, that GETTIMEOFFSET is needed. If you have a continuous counter that doesn't wrap for a reasonable number of ticks, you want to use the clocksource abstraction to represent that hardware. That has the benefits of allowing high res timers and nohz, since we don't need to keep a constant tick-beat to keep time (and also avoids lost-ticks and a host of problems that tick based timekeeping can run into).
So I suspect you probably want to verify your hardware supports a clocksource and disable ARCH_USES_GETTIMEOFFSET.
Sorry for any confusion!
thanks -john
| |