On Mon, Feb 11, 2008 at 08:58:46PM +0100, Mike Galbraith wrote: > > On Mon, 2008-02-11 at 11:26 -0600, Olof Johansson wrote: > > On Mon, Feb 11, 2008 at 09:15:55AM +0100, Mike Galbraith wrote: > > > Piddling around with your testcase, it still looks to me like things > > > improved considerably in latest greatest git. Hopefully that means > > > happiness is in the pipe for the real workload... synthetic load is > > > definitely happier here as burst is shortened. > > > > The real workload doesn't see much of an improvement. The changes I did > > when tinkering yesterday seem like they're better at modelling just > > what's going on with that one. > > So the real application is trying to yield? If so, you could try > prodding /proc/sys/kernel/sched_compat_yield.
The real application wasn't using yield, but it also didn't get hung up on the busy-wait loop, that was a mistake by me on Friday. Practically all the time of that application was spent in the actual workload loop. I tried adding a yield at the bottom loop, but it didn't make a significant difference. > It shouldn't matter if you yield or not really, that should reduce the > number of non-work spin cycles wasted awaiting preemption as threads > execute in series (the problem), and should improve your performance > numbers, but not beyond single threaded. > > If I plugged a yield into the busy wait, I would expect to see a large > behavioral difference due to yield implementation changes, but that > would only be a symptom in this case, no? Yield should be a noop. Exactly. It made a big impact on the first testcase from Friday, where the spin-off thread spent the bulk of the time in the busy-wait loop, with a very small initial workload loop. Thus the yield passed the cpu over to the other thread who got a chance to run the small workload, followed by a quick finish by both of them. The better model spends the bulk of the time in the first workload loop, so yielding doesn't gain at all the same amount. I still added it to rule out that it was a factor in the time differences. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/