On Mon, 2012-09-24 at 09:30 -0700, Linus Torvalds wrote: > On Mon, Sep 24, 2012 at 9:12 AM, Peter Zijlstra <a.p.zijls...@chello.nl> > wrote: > > > > So we're looking for an idle cpu around @target. We prefer a cpu of an > > idle core, since SMT-siblings share L[12] cache. The way we do this is > > by iterating the topology tree downwards starting at the LLC (L3) cache > > level. Its groups are either the SMT-siblings or singleton groups. > > So if it'sally guaranteed to be SMT-siblings or singleton groups, then > the whole "for_each_cpu()" is a total disaster. That's a truly > expensive way to look up adjacent CPU's. Is there no saner way to look > up that thing? Like a simple circular list of SMT siblings (I realize > that on x86 that list is either one or two, but other SMT > implementations are groups of four or more).
SMT siblings aren't actually adjacent in the cpu number space (on x86 at least). So the alternative you suggest is pointer chasing a list, is that really much better than scanning a mostly empty bitmap? I've no idea how bad these bitmap scanning instructions are on modern chips. But let me try and come up with the list thing, I think we've actually got that someplace as well. > So I suspect your patch largely makes things faster (avoid those > insane cpumask operations), but the for_each_cpu() one is still an > absolutely horrible way to find a couple of basically statically known > (modulo hotplug, which is disabled here anyway) CPU's. So even if the > algorithm makes sense at some higher level, it doesn't really seem to > make sense from an implementation standpoint. Agreed. > Also, do we really want to spread things out that aggressively? > How/why do we know that we don't want to share L2 caches, for example? > It sounds like a bad idea from a power standpoint, and possibly > performance too. IIRC this current stuff is the result of Mike and Suresh running a few benchmarks.. Mike, Suresh, either one of you remember this? Otherwise I'll have to go trawl the archives. -- 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/
