On Wed, 2012-09-26 at 23:37 +0200, Borislav Petkov wrote: > The way I understand it is, you either want to share L2 with a process, > because, for example, both working sets fit in the L2 and/or there's > some sharing which saves you moving everything over the L3. This is > where selecting a core on the same L2 is actually a good thing.
Yeah, and if the wakee can't get to the L2 hot data instantly, it may be better to let wakee drag the data to an instantly accessible spot. > Or, they're too big to fit into the L2 and they start kicking each-other > out. Then you want to spread them out to different L2s - i.e., different > HT groups in Intel-speak. > > Oh, and then there's the userspace spinlocks thingie where Mike's patch > hurts us. > > Btw, Mike, you can jump in anytime :-) I think the pgbench problem is more about latency for the 1 in 1:N than spinlocks. > So I'd say, this is the hard scheduling problem where fitting the > workload to the architecture doesn't make everyone happy. Yup. I find it hard at least. > A crazy thought: one could go and sample tasks while running their > timeslices with the perf counters to know exactly what type of workload > we're looking at. I.e., do I have a large number of L2 evictions? Yes, > then spread them out. No, then select the other core on the L2. And so > on. Hm. That sampling better be really cheap. Might help... but how does that affect pgbench and ilk that must spread regardless of footprints. -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/
