[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87imtskq46.fsf@vitty.brq.redhat.com>
Date: Thu, 30 May 2019 15:51:05 +0200
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Michael Kelley <mikelley@...rosoft.com>
Cc: "catalin.marinas\@arm.com" <catalin.marinas@....com>,
"mark.rutland\@arm.com" <mark.rutland@....com>,
"will.deacon\@arm.com" <will.deacon@....com>,
"marc.zyngier\@arm.com" <marc.zyngier@....com>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hyperv\@vger.kernel.org" <linux-hyperv@...r.kernel.org>,
"olaf\@aepfle.de" <olaf@...fle.de>,
"apw\@canonical.com" <apw@...onical.com>,
"jasowang\@redhat.com" <jasowang@...hat.com>,
"marcelo.cerri\@canonical.com" <marcelo.cerri@...onical.com>,
Sunil Muthuswamy <sunilmut@...rosoft.com>,
KY Srinivasan <kys@...rosoft.com>
Subject: RE: [PATCH v3 2/2] Drivers: hv: Move Hyper-V clocksource code to new clocksource driver
Michael Kelley <mikelley@...rosoft.com> writes:
> From: Vitaly Kuznetsov <vkuznets@...hat.com> Sent: Thursday, May 30, 2019 2:48 AM
>> > + /*
>> > + * sched_clock_register is needed on ARM64 but
>> > + * is a no-op on x86
>> > + */
>> > + sched_clock_register(read_hv_sched_clock_msr,
>> > + 64, HV_CLOCK_HZ);
>>
>> I'm not sure about ARM, but MSR-based clocksource would be a really bad
>> choice for sched clock on x86, this will slow things down
>> significantly. Luckily, as you're validly stating above,
>> sched_clock_register() is a no-op on x86 as we don't define
>> CONFIG_GENERIC_SCHED_CLOCK.
>>
>> Can we actually *not* do sched_clock_register() in case
>> TSC page is unavailable (and revert to counting jiffies or whatever)?
>>
>
> We can't skip the sched_clock_register() on ARM64 because it
> does define CONFIG_GENERIC_SCHED_CLOCK. However, Hyper-V
> should always provide REFERENCE_TSC_AVAILALBE on ARM64,
> so we should never end up in the MSR-based code on ARM64.
> Arguably that means the call to sched_clock_register() could be
> removed since it's a no-op on x86. But I'd like to keep it for symmetry
> and in case there's a testing/debugging situation on ARM64 where
> we want to clear REFERENCE_TSC_AVAILABLE and go down the
> MSR-based code path.
Ok, so it is just a fall-back and not going to be actively used. Thanks!
--
Vitaly
Powered by blists - more mailing lists