* Waiman Long <waiman.long@xxxxxx> wrote: > How about making the selection of MCS or ticket queuing either user > configurable or depending on the setting of NR_CPUS, NUMA, etc? No! There are lots of disadvantages to adding such CONFIG_NUMA Kconfig variants for locking primitives: - an doubling of the test matrix - an doubling of the review matrix and a halving of effective review capacity: we've just about go the capacity to review and validate patches like this. Splitting out a 'only NUMA cares' variant is a non-starter really. - but most importantly, there's absolutely no reason to not be fast on 128 CPU systems in the low contended case either! Sacrificing the low contended case with 'on 128 CPU systems it is the contended path that matters' is an idiotic argument. Essentially the only area were we allow Kconfig dependencies are unyielding physical forces: such as lots of CPUs needing a wider CPU mask. As Peter said it, the right solution is to fix the contended case. If that also happens to speed up or better organize the uncondended code then that's good, but it should not make it worse. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
