Re: [PATCH resend] clocksource: Defer override invalidation unless clock is unstable

[John Stultz]

On Wed, Jul 27, 2016 at 6:50 AM, Kyle Walker <kwalker@xxxxxxxxxx> wrote:
> On Tue, Jul 26, 2016 at 5:36 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
>> The logic here is confusing as well. So.. if the override is not HRT
>> compatible, we check if its stable or not?  Once we're in HRT there's
>> not much likelyhood of us going into non HRT mode. I'm not sure what
>> the stability has to do with it here.
>>
>> Sorry, could you explain the case you're running into in some further
>> detail?
>
> The issue I'm running into is that the override is not HRT compatible yet.
> Though it will be later in the boot process, unless the clocksource watchdog
> marks the clocksource as unstable.
>
> The issue with the current implementation is that the override_name value is
> disabled when the tsc is first checked, before the watchdog has a chance to
> check it and mark it stable or unstable.

Hrm. Ok. I've missed that the setting of a clocksource to being
VALID_FOR_HRES happens by the watchdog and was thinking it was more
like the IS_CONTINUOUS flag.

So with that detail made clear, the patch makes more sense. I'd
definitely clear up the change log to explain that detail:
"Clocksources don't get the VALID_FOR_HRES flag until they have been
checked by a watchdog. However, when using an override, the
clocksource_select logic will clear the override value if the
clocksources is not marked VALID_FOR_HRES on that check. When using
the boot arguments clocksource=<foo>, this selection can run before
the watchdog, and can cause the override to be incorrectly cleared."

Sorry for the slow response, keeping up with the merge window the last
two weeks has been a little crazy.

thanks
-john