On Fri, 2013-03-08 at 10:50 +0800, Michael Wang wrote: > > OK, so there's two issues I have with all this are: > > > > - it completely wrecks task placement for things like interrupts (sadly I > > don't > > have a good idea about a benchmark where this matters). > > I don't get this point...could you please give more details?
Take for instance a network workload, the hardirq notifies us there's data buffered, then softirq does a ton of network layer demuxing and eventually wakes one (or more) tasks to process data. You want these tasks to move to the waking cpu, it has lots of this data in cache. Now, neither hard- nor softirq runs in task context (except for -rt) so it completely fails on what you propose. We could simply add something like in_softirq() || in_irq() etc.. to re-enable wake_affine() for those cases unconditionally, but not sure that's the right thing either. > > - yet another random number.. :/ > > Correct...well, but that also means flexibility, I suppose different > system and workload will need some tuning on this knob to gain more > benefit, by default, they will gain some benefit, small or big. Nah, it just means another knob nobody knows how to twiddle. > > Also, I'm starting to dislike the buddy name; its somewhat over-used. > > I have to agree :), any suggestions? Nah.. I suppose it depends a bit on the shape the final solution takes, but I'll think about it. -- 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/
