lkml.org 
[lkml]   [2008]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [git pull] scheduler updates
On Sat, Nov 08, 2008 at 11:29:57AM -0800, Ingo Molnar wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > On Sat, 8 Nov 2008, Ingo Molnar wrote:
> > >
> > > So that's why my change moves it from the __native_read_tsc() over to
> > > _only_ the vget_cycles().
> >
> > Ahh. I was looking at native_read_tscp(). Which has no barriers. But then
> > we don't actually save the actual TSC, we only end up using the "p" part,
> > so we don't care..
> >
> > Anyway, even for the vget_cycles(), is there really any reason to
> > have _two_ barriers? Also, I still think it would be a hell of a lot
> > more readable and logical to put the barriers in the _caller_, so
> > that people actually see what the barriers are there for.
> >
> > When they are hidden, they make no sense. The helper function just
> > has two insane barriers without explanation, and the caller doesn't
> > know that the code is serialized wrt something random.
>
> ok, fully agreed, i've queued up the cleanup for that, see it below.
>
> sidenote: i still kept the get_cycles() versus vget_cycles()
> distinction, to preserve the explicit marker that vget_cycles() is
> used in user-space mode code. We periodically forgot about that in the
> past. But otherwise, the two inline functions are now identical.
> (except for the assymetry of its inlining, and the comment about the
> boot_cpu_data use of the has_tsc check)
>


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?

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

---
arch/x86/kernel/tsc_sync.c | 4 ++++
1 file changed, 4 insertions(+)

Index: linux-2.6/arch/x86/kernel/tsc_sync.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/tsc_sync.c 2008-11-10 15:27:12.000000000 -0800
+++ linux-2.6/arch/x86/kernel/tsc_sync.c 2008-11-17 14:13:17.000000000 -0800
@@ -46,7 +46,9 @@ static __cpuinit void check_tsc_warp(voi
cycles_t start, now, prev, end;
int i;

+ 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();
last_tsc = now;
__raw_spin_unlock(&sync_lock);


\
 
 \ /
  Last update: 2008-11-17 23:47    [W:0.528 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site