Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
From: Waiman Long
Date: Wed Feb 05 2014 - 22:09:52 EST
On 02/02/2014 04:03 AM, Ingo Molnar wrote:
* 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
You are right. I am trying to measure the performance impact of MCS
queuing has on a lightly contended system. I need to write some custom
test code to get that information. With that information, I may be able
to tune it to perform more or less on par with ticket lock.
As for the additional cache line access of the MCS lock, I don't think
it is really an issued as the MCS node is allocated on local stack which
is likely to be in the cache anyway. I will report back when I have more
data.
-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/