lkml.org 
[lkml]   [1999]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Better lmbench 2.2.14pre4 vs. 2.3.28
Date
In article <Pine.LNX.4.10.9911161509270.4535-100000@chiara.csoma.elte.hu>,
Ingo Molnar <mingo@chiara.csoma.elte.hu> wrote:
>
>i'm quite sure these are due to the scheduling heuristics removed in 2.3 -
>we are running two lmbench processes on two CPUs, which causes excessive
>cross-CPU (and main memory) traffic. Will think about how to solve this
>cleanly.

I know how to solve it right, but "cleanly"?

The problem is that certain events are really of the type "wake up
somebody else, and then I will go to sleep".

This is true of the pipe case, for example: we've filled the write
buffer, and we want to wake up the reader and go to sleep (or we're the
reader and we've emptied the buffer and want to go to sleep).

In that case, all of our current clever "select a good CPU to schedule
for the wakeup" is just so much crap: we should not waste precious CPU
cycles doing that, considering that the current thread is "synchronous"
wrt the event in question anyway, and we're probably a lot better off
just trying to do a nice clean single-CPU re-schedule from the producer
to the consumer (or back).

In short, what we really want is a "synchronous wakeup": a wakeup that
does not imply the "search for a good CPU" heuristic.

The problem is that unlike the "WAKEONE" thing, where it is the
_sleeper_ that wants to say that it's a special kind of sleeper, this
case it's the person who does the wakeup() that wants to tell the world
that it's a special kind of waker that wants to wake people up in order
for them to do some more work for it. And we don't have a very nice way
of doing that right now, I'm afraid.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.047 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site