On 02/22/2013 05:57 PM, Peter Zijlstra wrote: > On Fri, 2013-02-22 at 17:11 +0800, Michael Wang wrote: > >> Ok, it do looks like wake_affine() lost it's value... > > I'm not sure we can say that on this one benchmark, there's a > preemption advantage to running on a single cpu for pipe-test as well. > We'd need to create a better benchmark to test this, one that has some > actual data payload and control over the initial spread of the tasks or > so. > >>> Now as far as I can see there's two options, either we find there's >>> absolutely no benefit in wake_affine() as it stands today and we simply >>> disable/remove it, or we go fix it. What we don't do is completely >>> wreck it at atrocious cost. >> >> I get your point, we should replace wake_affine() with some feature >> which could really achieve the goal to make client and server on same cpu. >> >> But is the logical that the waker/wakee are server/client(or reversed) >> still works now? that sounds a little arbitrary to me... > > Ah, its never really been about server/client per-se. Its just a > specific example -- one that breaks down with the 1:n pgbench > situation. > > Wakeups in general can be considered to be a relation, suppose a > hardware interrupt that received some data from a device and issues a > wakeup to a task to consume this data. What CPU would be better suited > to process this data then the one where its already cache hot.
I see, honestly, I realized that I have underestimated the benefit we gain from it when saw your testing results... We do need some better approach to replace wake_affine(), hmm...I need a draft board now... Regards, Michael Wang > -- 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/
