instability of timekeeping

[Andriy Gapon]

On 21/10/2015 21:48, Konstantin Belousov wrote:
> Am I right that the tsc synchronization test passes on your machine ?

Yes.

> If yes, you probably cannot read 'slightly behind' timecounter after IPI
> on other core.

Right.  But please note that my hypothesis does not require that the following
is true: CPU_A reads TSC value X, CPU_A sends an IPI to CPU_B, CPU_B gets the
IPI, CPU_B reads TSC value Y, Y < X.  In my configuration there is one master
CPU and 3 slaves. Also, it could be possible that the IPI is delayed for so long
that there is an interaction between handling of 2 consecutive hardclock IPIs.

> Might be, try to change CPUID instruction in the test to
> MFENCE and see if the test still able to pass.
> Does the symptom disappear if you switch the eventtimer to LAPIC ?

And now another observation.  I have C1E option enabled in BIOS.  It means that
if all cores enter C1 state, then the whole processor is magically placed into a
deep C-state (C3, I think).  LAPIC timer on this CPU model does not run in the
deep C-state.  So, I had to disable C1E option to test the LAPIC timer in a
useful way.  But before actually testing it I first tried to reproduce the problem.
As you might have already guessed the problem is gone with that option disabled.
Scratching my head to understand the implications of this observation.

> What happens if you turn off usermode gettimeofday()
> by setting kern.timercounter.fast_gettime to 0 ?


-- 
Andriy Gapon