Re: [Xen-devel] [PATCH] x86/time: use correct (local) time stamp in constant-TSC calibration fast path

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.06.16 at 17:00, <joao.m.martins@xxxxxxxxxx> wrote:
> On 06/09/2016 01:57 PM, Jan Beulich wrote:
>>>>> On 09.06.16 at 14:11, <joao.m.martins@xxxxxxxxxx> wrote:
>> So in effect for the fast path the patch
>> changes the situation from c->stime_local_stamp being effectively
>> unused to c->stime_master_stamp being so. In the former case, if
>> that really hadn't been a typo, deleting the write of that field from
>> time_calibration_std_rendezvous() would have made sense, as
>> get_s_time() certainly is more overhead than the simply memory
>> read and write needed for keeping c->stime_master_stamp up to
>> date (despite not being used).
> I agree, but what I meant previously was more of a concern meaning: CPU 0 is 
> doing an
> expensive read_platform_time (e.g. HPET supposedly microseconds order, plus 
> a
> non-contented lock) to set stime_master_stamp that doesn't get used at all -
> effectively not using the clocksource set initially at boot.

Yeah, there's likely some cleanup potential here, but of course we
need to be pretty careful about not doing something that may be
needed by some code paths but not others. But if you think you
can help the situation without harming maintainability, feel free to
go ahead.

> What if verify_tsc_reliability clears out X86_FEATURE_TSC_RELIABLE when 
> failing
> the warp test? The calibration function is set early on right after 
> interrupts are
> enabled and the time warp check later on when all CPUs are up. So on 
> problematic
> platforms it's possible that std_rendezvous is used with a constant TSC but 
> still
> deemed unreliable. We still keep incrementing deltas at roughly about the 
> same time,
> but in effect with this change the stime_local_stamp would be TSC-only based 
> thus
> leading to warps with an unreliable TSC? And there's also the CPU 
> hotplug/onlining
> case that we once discussed.

I agree that we're likely in trouble in such a case. But for the
moment I'd be glad if we could get the "normal" case work right.

Jan


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