On Mon, 2013-06-03 at 11:26 +0800, Michael Wang wrote: > On 06/03/2013 11:09 AM, Mike Galbraith wrote: > > On Mon, 2013-06-03 at 10:28 +0800, Michael Wang wrote: > >> On 05/28/2013 01:05 PM, Michael Wang wrote: > >>> wake-affine stuff is always trying to pull wakee close to waker, by > >>> theory, > >>> this will bring benefit if waker's cpu cached hot data for wakee, or the > >>> extreme ping-pong case. > >>> > >>> And testing show it could benefit hackbench 15% at most. > >>> > >>> However, the whole stuff is somewhat blindly and time-consuming, some > >>> workload therefore suffer. > >>> > >>> And testing show it could damage pgbench 50% at most. > >>> > >>> Thus, wake-affine stuff should be smarter, and realise when to stop > >>> it's thankless effort. > >> > >> Is there any comments? > > > > (I haven't had time to test-drive yet, -rt munches time like popcorn) > > I see ;-) > > During my testing, this one works well on the box, solved the issues of > pgbench and won't harm hackbench any, I think we have caught some good > point here :)
Some wider spectrum testing needs doing though. Hackbench is a good sign, but localhost and db type stuff that really suffer from misses would be good to test. Java crud tends to be sensitive too. I used to watch vmark (crap) as an indicator, if you see unhappiness there, you'll very likely see it in other loads as well, it is very fond of cache affine wakeups, but loathes preemption (super heavy loads usually do). -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
