>>> On 21.09.16 at 11:20, <joao.m.mart...@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).


Xen-devel mailing list

Reply via email to