Re: [PATCH v4 2/5] x86/time: implement tsc as clocksource

[Joao Martins <joao.m.martins@oracle.com>]

On 09/20/2016 11:15 AM, Joao Martins wrote:
> On 09/20/2016 08:13 AM, Jan Beulich wrote:
>>>>> On 19.09.16 at 19:54, <joao.m.martins@oracle.com> wrote:
>>> On 09/19/2016 05:25 PM, Jan Beulich wrote:
>>>>>>> On 19.09.16 at 18:11, <joao.m.martins@oracle.com> wrote:
>>>>> On 09/19/2016 11:13 AM, Jan Beulich wrote:
>>>>>>>>> On 14.09.16 at 19:37, <joao.m.martins@oracle.com> wrote:
>>>>>>> Since b64438c7c ("x86/time: use correct (local) time stamp in
>>>>>>> constant-TSC calibration fast path") updates to cpu time use local
>>>>>>> stamps, which means platform timer is only used to seed the initial
>>>>>>> cpu time.  With clocksource=tsc there is no need to be in sync with
>>>>>>> another clocksource, so we reseed the local/master stamps to be values
>>>>>>> of TSC and update the platform time stamps accordingly. Time
>>>>>>> calibration is set to 1sec after we switch to TSC, thus these stamps
>>>>>>> are reseeded to also ensure monotonic returning values right after the
>>>>>>> point we switch to TSC. This is also to avoid the possibility of
>>>>>>> having inconsistent readings in this short period (i.e. until
>>>>>>> calibration fires).
>>>>>>
>>>>>> And within this one second, which may cover some of Dom0's
>>>>>> booting up, it is okay to have inconsistencies?
>>>>> It's not okay which is why I am removing this possibility when switching to TSC.
>>>>> The inconsistencies in those readings (if I wasn't adjusting) would be because
>>>>> we would be using (in that 1-sec) those cpu time tuples calculated by the
>>>>> previous calibration or platform time initialization (while still was HPET,
>>>>> ACPI, etc as clocksource). Would you prefer me removing the "avoid" and instead
>>>>> change it to "remove the possibility" in this last sentence?
>>>>
>>>> Let's not do the 2nd step before the 1st, which is the question of
>>>> what happens prior to and what actually changes at this first
>>>> calibration (after 1 sec).
>>> The first calibration won't change much - this 1-sec was meant when having
>>> nop_rendezvous which is the first time platform timer would be used to set local
>>> cpu_time (will adjust the mention above as it's misleading for the reader as it
>>> doesn't refer to this patch).
>>
>> So what makes it that it actually _is_ nop_rendezvous after that one
>> second? (And yes, part of this may indeed be just bad placement of
>> the description, as iirc nop_rendezvous gets introduced only in a later
>> patch.)
> Because with nop_rendezvous we will be using the platform timer to get a
> monotonic time tuple and *set* cpu_time as opposed to just adding up plain TSC
> delta as it is the case prior to b64438c7c. Thus the reseeding of the cpu times
> solves both ends of the problem, with nop_rendezvous until it is first
> calibration fixes it, and without nop_rendezvous to remove the latch adjustment
> from initial platform timer.
The part "until it is the first calibration fixes it" is very
confusing/redundant I am sorry. I meant it: "with nop_rendezvous which otherwise
would be the first calibration fixing it". The previous part was hinting like
there's a problem, when it is fixed but the reseeding.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel