[lkml]   [2019]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] Revert "x86/hpet: Reduce HPET counter read contention"
On Fri, Mar 15, 2019 at 10:25:29AM +0100, Peter Zijlstra wrote:
> On Thu, Mar 14, 2019 at 04:42:12PM +0800, Zhenzhong Duan wrote:
> > This reverts commit f99fd22e4d4bc84880a8a3117311bbf0e3a6a9dc.
> >
> > It's unnecessory after commit "acpi_pm: Fix bootup softlockup due to PMTMR
> > counter read contention", the simple HPET access code could be restored.
> >
> > On a general system with good TSC, TSC is the final default clocksource.
> > So the potential performce loss is only at bootup stage before TSC
> > replacing HPET, we didn't observe obvious delay of bootup.
> The timeline here is:
> - Len took out SKX from native_calibrate_tsc
> b51120309348 ("x86/tsc: Fix erroneous TSC rate on Skylake Xeon")
> This causes the TSC to run through the calibration code, which
> completes _after_ SMP bringup.
> - This then caused HPET to be used during SMP bringup, which resulted
> in Waiman doing the patch you now propose removing.
> Because large (multi-socket) SKX machines would barely boot.
> f99fd22e4d4b ("x86/hpet: Reduce HPET counter read contention")

Damn, my memory tricked me.. I just checked the dates on those patches
and I got it in reverse.

Anyway, the point still stands, when TSC is wrecked we still need HPET.
And you don't see a difference with the revert because of
clocksource_tsc_early, which didn't exist at the time.

 \ /
  Last update: 2019-03-15 10:29    [W:0.040 / U:15.304 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site