[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/tsc: limit the usage of synchronization rendezvous
On 23.10.2019 15:56, Roger Pau Monne wrote: > If Xen detects the TSC is unreliable it will set a rendezvous helper > that tries to synchronize the different CPUs TSC value by propagating > the one from CPU#0 and writing it into the IA32_TSC MSR on each CPU. > > When the system has a single thread and there are no hotplugable CPUs > doing the above just results in reading the TSC from CPU#0 and writing > it into the IA32_TSC MSR of CPU#0, which is pointless, so limit the > usage of the synchronization rendezvous to systems that have more than > one CPU, even if those CPUs are yet to be hotplugged. > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> > --- > I'm not sure whether this is suitable for 4.13, being a performance > improvement but not fixing a functional bug. Unless we know there's a lot of use of Xen in UP mode, I'd say rather not. _If_ there was a lot of such use, then I think we ought to do more work towards performance there (like re- introducing SMP alternatives patching). Of course in the end the decision is to be taken by Jürgen, whom you didn't even Cc. > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -1821,7 +1821,8 @@ static int __init verify_tsc_reliability(void) > * are not marked as 'reliable', re-sync during rendezvous. > */ > if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && > - !boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ) > + !boot_cpu_has(X86_FEATURE_TSC_RELIABLE) && > + num_present_cpus() > 1 ) > time_calibration_rendezvous_fn = time_calibration_tsc_rendezvous; Did you consider the alternative of switching the rendezvous function when going from UP to MP mode (or back)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |