Message-ID: <CAEPKNTJLPf-md3i4r74qy=BjAYC38KCUQM3UhTZED7JvL9j1TQ@mail.gmail.com>
Date:	Wed, 27 Jul 2016 10:29:06 -0400
From:	Kyle Walker <kwalker@...hat.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH resend] clocksource: Defer override invalidation unless
 clock is unstable

I'm so sorry for the duplicate, gmail managed to sneak in some HTML.
Resending due to the mailing list correctly blocking the initial send.

On Tue, Jul 26, 2016 at 5:36 PM, John Stultz <john.stultz@...aro.org> wrote:
> Sorry for not getting back to you. This has been in my to-look-at list.


No problem at all. Thanks for taking a look!


> On Tue, Jul 26, 2016 at 2:24 PM, Kyle Walker <kwalker@...hat.com> wrote:
>> The clock_select() operation will attempt to use the clocksource override
>> to apply the desired clocksource when the "clocksource=" boot parameter is
>> supplied. However, in the event that "clocksource=tsc" is used on a system
>> where there is a more desireable clocksource available, the boot parameter
>> fails. This is due to the TSC clocksource being installed unvalidated, but
>> the override being invalidated during the initial run through
>> clocksource_done_booting().
>
> I've read this a few times, and I'm not sure I really understand it.
>
> Can you give an example of a "more desirable clocksource" then the
> TSC?  Especially when the TSC was specified as a boot argument?
>

I apologize for the confusion. By "more desireable", I mean that there is
another clocksource that the system is wanting to use by default. For
example, on Xen platforms, the "xen" clocksource is the "best" as
determined by clocksource_find_best(), being at the top of the list.

crash> list -s clocksource.name,rating clocksource.list -H clocksource_list
ffffffff81c0cb00
  name = 0xffffffff817ad585 "xen"
  rating = 400
ffffffff81a98540
  name = 0xffffffff817c2873 "tsc"
  rating = 300
ffffffff81aa6580
  name = 0xffffffff817b118a "hpet"
  rating = 250
ffffffff81b22b00
  name = 0xffffffff817c02b7 "acpi_pm"
  rating = 120
ffffffff81ab48c0
  name = 0xffffffff817c05c6 "jiffies"
  rating = 1


In that scenario, the xen clocksource would be used if no override was
specified.


>
> 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.

Without patch:
$ dmesg | grep -e clocksource
<snip>
clocksource: refined-jiffies: <snip>
Kernel command line: <snip> clocksource=tsc
clocksource: hpet: <snip>
clocksource: xen: <snip>
clocksource: jiffies: <snip>
clocksource: Switched to clocksource xen
clocksource: acpi_pm: <snip>
tsc: Refined TSC clocksource calibration: 2394.399 MHz

clocksource: tsc: <snip>
clocksource: Override clocksource tsc is not HRT compatible - <snip>


With patch:
$ dmesg | grep -e clocksource
<snip>
clocksource: refined-jiffies:<snip>
Kernel command line: <snip> clocksource=tsc
clocksource: hpet: <snip>
clocksource: xen: <snip>

clocksource: jiffies: <snip>
clocksource: Switched to clocksource xen
clocksource: acpi_pm: <snip>
tsc: Refined TSC clocksource calibration: 2394.461 MHz
clocksource: tsc: <snip>
clocksource: Override clocksource tsc is not currently HRT compatible
- deferring
clocksource: Switched to clocksource tsc


Please let me know if there is any further clarification needed. Have a good
one!

--
Kyle Walker

Powered by blists - more mailing lists