Messages in this thread | | | Date | Sun, 7 Aug 2011 01:36:42 +0100 | From | Matthew Garrett <> | Subject | Re: [PATCH v2] x86: Reduce clock calibration time during slave cpu startup |
| |
On Fri, Aug 05, 2011 at 11:38:36PM +0200, Ingo Molnar wrote:
> Well, it still uses heuristics: it assumes frequency is the same when > the cpuid data tells us that two CPUs are on the same socket, right?
If we only assume that when we have a constant TSC then it's a pretty safe assumption - the delay loop will be calibrated against the TSC, and the TSC will be constant across the package regardless of what frequency the cores are actually running at.
> Cannot we directly see the frequency(ies) of the CPU, and decide > based on that whether the calibration result can be cached?
Kind of? We can look at the aperf/mperf ratio and compare that against the TSC to work out the frequency. But that only gives you meaningful results with a constant TSC, so since you're still depending on that you might as well skip the extra check.
The only time this should give problems is if someone produces a multi-core x86 with per-core (rather than per-package) TSC and runs the TSC at different frequencies per-core. Since that'd probably cost more than not doing it, I think we're probably safe.
-- Matthew Garrett | mjg59@srcf.ucam.org
| |