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

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

On 09/21/2016 10:45 AM, Jan Beulich wrote:
>>>> On 21.09.16 at 11:20, <joao.m.martins@oracle.com> wrote:
>> On 09/20/2016 05:17 PM, Joao Martins wrote:
>>> On 09/20/2016 02:55 PM, Jan Beulich wrote:
>>>> I.e. the introduction of nop_rendezvous is
>>>> really just to avoid unnecessary overhead?
>>> Yes, but note that it's only the case since recent commit b64438c7c where
>>> cpu_time stime is now incremented with TSC based deltas with a matching TSC
>>> stamp. Before it wasn't the case. The main difference with nop_rendezvous (other
>>> than the significant overhead) versus std_rendezvous is that we use a single
>>> global tuple propagated to all cpus, whereas with std_rendezvous each tuple is
>>> different and will vary according to when it rendezvous with cpu 0.
>>>
>>>> In which case it should
>>>> probably be a separate patch, saying so in its description.
>>> OK, will move that out of Patch 4 into its own while keeping the same logic.
>> I have to take back my comment: having redouble-checked on a test run overnight
>> with std_rendezvous and stable bit, and I saw time going backwards a few times
>> (~100ns) but only after a few hours (initially there were none - probably why I
>> was led into error). This is in contrast to nop_rendezvous where I see none in
>> weeks.
> 
> Hmm, that would then seem to call for the introduction of
> nop_rendezvous to be pulled ahead in the series (presumably into
> the very patch we're discussing here).
Seems like it. I will move it into this patch, in which case patch 3 needs to be
moved before this one (since it's a prerequisite patch).

Joao

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