lkml.org 
[lkml]   [2008]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [git pull] scheduler updates

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 8 Nov 2008, Arjan van de Ven wrote:
> >
> > historically it was for early AMD cpus (K7, not sure if early K8 did
> > this) where 2 consecutive rdtsc's in the same codestream would get
> > reordered compared to eachother, so you could observe the tsc go
> > backwards...
>
> .. but this only happens with two _consecutive_ ones.
>
> The thing is, nobody sane does that in generic code. The scheduler wants
> to have cycles, yes, but two consecutive scheduler invocations will have
> spinlocks etc in between. That's true of _all_ sane uses of a TSC.
>
> I don't see that there is ever any reason to do the barriers for any
> normal case. And the cases where it does matter would actually be worth
> pointing out (ie making the barriers explicit in those cases, and those
> cases only).
>
> Doing it in get_cycles() and "forgetting about it" may sound like a simple
> solution, but it's likely wrong. For example, one of the few cases where
> we realy care about time going backwards is gettimeofday() - which uses
> tsc, but which also has tons of serializing instructions on its own.
> EXCEPT WHEN IT IS a vsyscall!
>
> But in that case, we don't even have the barrier, because we put it in the
> wrong function and 'forgot about it'. Of course, we may not need it
> (rdtscp maybe always serializes, I didn't check), but the point is, an
> explicit barrier is actually better than one that is hidden.
>
> So who _really_ needs it? And why not just do it there?

i think, the tree as offered to you, intends to do just that, unless i
made some grave (and unintended) mistake somewhere.

The barrier is only present in the vread function: which is the
vsyscall-read function, to be used from user-space.

Even in the past, no was actually forgotten or put in the wrong
function as far as i can see because previously _everything_
(including the vread method) had the barrier.

The change from me simply removes the barrier from the places that
dont need it - exactly for the reason you outlined: the scheduler is
both imprecise and has a ton of natural serialization anyway, so it's
a non-issue there.

Hm?

Ingo


\
 
 \ /
  Last update: 2008-11-08 20:13    [W:0.104 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site