Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle

[John Stultz]

On Mon, Jul 6, 2015 at 10:34 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Mon, 6 Jul 2015, John Stultz wrote:
>> On Mon, Jul 6, 2015 at 12:12 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
>> > Some persistent clocksources can be on a slow external bus. For shorter
>> > latencies for RT use, let's allow toggling the clocksource during idle
>> > between a faster non-persistent runtime clocksource and a slower persistent
>> > clocksource.
>>
>> So yea, as Thomas mentioned, this will cause problems for timekeeping
>> accuracy, since we end up resetting the ntp state when we change
>> clocksource (additionally you gain a bit of error each time you switch
>> clocksources). So you'll most likely see trouble w/ ntpd steering the
>> clock.
>>
>> I'm not sure its quite clear in the description as to the need here.
>> Could you expand a bit as to the rational for why?  I assume it has to
>> do with you have a high-res clocksource that is good for fine-grained
>> clock_gettime() calls, but wraps quickly, making it poor for long idle
>> times. So you're trying to swap to a less fine grained clocksource
>> that won't wrap so fast?
>>
>> The persistent-clock-like name muddies things further, since the
>> persistent-clock is used for suspend, while it looks like this is just
>> for idle times.
>
> Though that are idle states where the cpu is powered off so the fast
> clock source is powered off as well....
>
> We all know how well that works from the x86/TSC horror. It's just the
> same thing again with a different arch prefix.

Right.. and it might be telling that on x86 systems with this issue,
we don't play games with it and that sort of hardware just has to use
the slower and less fine-grained clocksources all the time.

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