Messages in this thread | | | Date | Tue, 18 Nov 2008 00:13:05 +0100 | From | Ingo Molnar <> | Subject | Re: [git pull] scheduler updates |
| |
* Venki Pallipadi <venkatesh.pallipadi@intel.com> wrote:
> On Mon, Nov 17, 2008 at 02:50:18PM -0800, Ingo Molnar wrote: > > > > * Venki Pallipadi <venkatesh.pallipadi@intel.com> wrote: > > > > > Patch being discussed on this thread (commit 0d12cdd) has a > > > regression on one of the test systems here. > > > > > > With the patch, I see > > > > > > checking TSC synchronization [CPU#0 -> CPU#1]: > > > Measured 28 cycles TSC warp between CPUs, turning off TSC clock. > > > Marking TSC unstable due to check_tsc_sync_source failed > > > > > > Whereas, without the patch syncs pass fine on all CPUs > > > > > > checking TSC synchronization [CPU#0 -> CPU#1]: passed. > > > > > > Due to this, TSC is marke unstable, when it is not actually unstable. > > > This is because syncs in check_tsc_wrap() goes away due to this commit. > > > > > > As per the discussion on this thread, correct way to fix this is to add > > > explicit syncs as below? > > > > ah. Yes. > > > > Could you please check whether: > > > > > + rdtsc_barrier(); > > > start = get_cycles(); > > > + rdtsc_barrier(); > > > /* > > > * The measurement runs for 20 msecs: > > > */ > > > @@ -61,7 +63,9 @@ static __cpuinit void check_tsc_warp(voi > > > */ > > > __raw_spin_lock(&sync_lock); > > > prev = last_tsc; > > > + rdtsc_barrier(); > > > now = get_cycles(); > > > + rdtsc_barrier(); > > > > adding the barrier just _after_ the get_cycles() call (but not before > > it) does the trick too? That should be enough in this case. > > > > With barrier only after get_cycles, I do see syncs across first few > CPUs passing. But later I see: > > checking TSC synchronization [CPU#0 -> CPU#13]: Measured 4 cycles > TSC warp between CPUs, turning off TSC clock. Marking TSC unstable > due to check_tsc_sync_source failed
yeah - has to be surrounded, to make sure our last_tsc observation does not happen after the RDTSC.
I have applied your patch to tip/x86/urgent, thanks!
Ingo
| |