On 07/18/2013 08:55 AM, George Spelvin wrote:
In the interest of more useful Kconfig help, could I recommend the following text: config QUEUE_RWLOCK bool "Generic queue read/write lock" depends on ARCH_QUEUE_RWLOCK help Use an alternative reader-writer lock (rwlock) implementation, optimized for larger NUMA systems. These locks use more memory, but perform better under high contention. (Specifically, readers waiting for a writer to release the lock will be queued rather than all spinning on the same cache line.) The kernel will operate correctly either way; this only affects performance. For common desktop and server systems systems with only one or two CPU sockets, the performance benefits are not worth the additional memory; say N here. My goal is to give someone stumbling across this question for the first time in "make oldconfig" the information htey need to answer it.
Thank for the revision, I will make such a change in the next version of my patch.
That said, I think Ingo's idea for simplfying the waiting reader side is excellent and should be tried before bifurcating the implementation. Looking at the lock system, it *seems* like that patch to __read_lock_failed is literally the *only* thing that needs changing, since the write lock/unlock is all done with relative add/sub anyway. But I keep thinking "there must have been a reason why it wasn't done that way in the first place".
As I said in my response to Ingo, that change will make the lock more unfair to the writers. However, I can run some tests to find out the performance impact of such a way on the benchmarks that I used.
Regards, Longman -- 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
