Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: Better lmbench 2.2.14pre4 vs. 2.3.28 | Date | 20 Nov 1999 02:27:47 GMT |
| |
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/
| |