[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220509073003.GB40730@shbuild999.sh.intel.com>
Date: Mon, 9 May 2022 15:30:03 +0800
From: Feng Tang <feng.tang@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...el.com>,
"H . Peter Anvin" <hpa@...or.com>,
Jonathan Corbet <corbet@....net>, x86@...nel.org,
linux-kernel@...r.kernel.org, paulmck@...nel.org,
rui.zhang@...el.com, len.brown@...el.com, tim.c.chen@...el.com
Subject: Re: [PATCH] x86/tsc: Add option to force HW timer based recalibration
Hi Peter,
Thanks for the review!
On Mon, May 09, 2022 at 09:16:52AM +0200, Peter Zijlstra wrote:
> On Mon, May 09, 2022 at 12:58:39PM +0800, Feng Tang wrote:
> > Sorry, just spotted some typos, here is the updated version
> >
> >
> > From ee8e3d772c623d27d79c43da5a76fb6252175aba Mon Sep 17 00:00:00 2001
> > From: Feng Tang <feng.tang@...el.com>
> > Date: Sun, 8 May 2022 20:22:12 +0800
> > Subject: [PATCH] x86/tsc: Add option to force HW timer based recalibration
> >
> > Currently when HW provides the tsc freq info through MSR or CPUID(0x15),
> > the info will be taken as the 'best guess', and kernel will set the
> > X86_FEATURE_TSC_KNOWN_FREQ flag and skip the HW timer based recalibration,
> > which works pretty well.
> >
> > And there is still very few corner case that the freq info is not
> > accurate enough with small deviation from the actual value, like on
> > a product with early buggy version of firmware or on some
> > pre-production hardware.
> >
> > Add an option 'recalibrate' for 'tsc' kernel parameter to force the
> > tsc freq recalibration with HPET/PM_TIMER, and warn if the deviation
> > from previous value is more than about 500 PPM.
> >
> > Signed-off-by: Feng Tang <feng.tang@...el.com>
>
> Why isn't 'tsc_early_khz=' not working for you? Afaict that will
> override calibrate_tsc() when provided and as such can be used on these
> early platforms for provide the right value until such time that the
> firmware is fixed.
For the early platforms, the problem we met is we don't know what
is the 'correct' tsc-freq, and the value from MSR/CUPID could be wrong.
And there was some generation, that after enabling some feature, each
instance of HW will have slightly different frequency, so there is
no central "one for all" value to set for 'tsc_early_khz'.
This option is more like a way to double-check the correctness of
tsc-freq got from MSR/CPUID(0x15).
Thanks,
Feng
Powered by blists - more mailing lists