[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <281ff50e-ea79-b006-57e9-e80a2728419b@oracle.com>
Date: Thu, 28 Sep 2017 09:11:19 -0400
From: Pasha Tatashin <pasha.tatashin@...cle.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>
Cc: Dou Liyang <douly.fnst@...fujitsu.com>, linux@...linux.org.uk,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
john.stultz@...aro.org, sboyd@...eaurora.org, x86@...nel.org,
linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com
Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early
in boot
>>> It will be best if we can support TSC sync capability in x86, but seems
>>> is not easy.
>>
>> Sure, your hardware achieving sync would be best, but even if it does
>> not, we can still use TSC. Using notsc simple because you fail to sync
>> TSCs is quite crazy.
>>
>> The thing is, we need to support unsync'ed TSC in any case, because
>> older chips (pre Nehalem) didn't have synchronized TSC in any case, and
>> it still happens on recent chips if the BIOS mucks it up, which happens
>> surprisingly often :-(
>>
>> I would suggest you try your reconfigurable setup with "tsc=unstable"
>> and see if that works for you. That marks the TSC unconditionally
>> unstable at boot and avoids any further wobbles once the TSC watchdog
>> notices (although that too _should_ more or less work).
>
> That should do the trick nicely and we might just end up converting notsc
> to tsc=unstable silently so we can avoid the bike shed discussions about
> removing it.
>
Ok, I will start working on converting notsc to unstable, and modify my
patches to do what Peter suggested earlier. In the mean time, I'd like
to hear from Dou if this setup works with dynamic reconfig.
Thank you,
Pasha
Powered by blists - more mailing lists