check_tsc_time_warp() (was Re: [PATCH] x86: skip delays during SMP initialization similar to Xen)

[Len Brown]

On Sun, May 17, 2015 at 1:26 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:

>> check_tsc_warp() is hard-coded to take 2ms. I don't know if 2ms is a
>> magic number or if shorter has same value. It seems a bit sad to do
>> this serially for every CPU at boot, when we could do all the CPUs
>> in parallel after they are on-line. Perhaps this should be invoked
>> only for boot-time and hot-add time. It shouldn't be needed at all
>> for soft online and resume.
>
> So how come the TSC isn't X86_FEATURE_CONSTANT_TSC?
> That should skip the TSC sync-test.

It appears that X86_FEATURE_TSC_RELIABLE (and tsc_clocksource_reliable)
have the sole purpose of avoiding check_tsc_warp().

However, that flag is set only if cmdline "tsc=reliable" or if
some SOC-specific code sets it.

X86_FEATURE_CONSTANT_TSC and
X86_FEATURE_NONSTOP_TSC are both set, but
they do not prevent every CPU from running check_tsc_warp().

I expect that on a single socket system that if
X86_FEATURE_CONSTANT_TSC and
X86_FEATURE_NONSTOP_TSC are set,
then we should be setting X86_FEATURE_TSC_RELIABLE
and thus skipping check_tsc_warp(), both at boot-time,
and also at resume-time.

Indeed, we may be able to safely set it for mullti-node
systems, but I'm not sure how to draw the line between
when this debug code should run and when it just wastes time.

Several other possibilities come to mind.
1. keep check_tsc_warp(), but run for less than 2ms
2. run check_tsc_warp() for multiple cpus in parallel instead of serially.
3. run test only for (system_state == SYSTEM_BOOTING)
    that would help suspend, but hot-add after boot may also want this debug.

I'm inclined to simply skip this test for single node systems
with constant+nonstop tsc.  Thoughts?

thanks,
Len Brown
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/