On Mon, 2013-07-15 at 16:08 -0700, Andrew Morton wrote: > On Mon, 15 Jul 2013 17:24:32 +1000 David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > I have previously proposed a correct method of improving scalability, > > although it doesn't eliminate the lock. That's to use a set of hashed > > mutexes. > > Yep - hashing the mutexes is an obvious and nicely localized way of > improving this. It's a tweak, not a design change. > > The changelog should describe the choice of the hash key with great > precision, please. It's important and is the first thing which > reviewers and readers will zoom in on. > > Should the individual mutexes be cacheline aligned? Depends on the > acquisition frequency, I guess. Please let's work through that. In my test cases, involving different RDBMS, I'm getting around 114k acquisitions. > > Let's not damage uniprocesor kernels too much. AFACIT the main offender > here is fault_mutex_hash(), which is the world's most obfuscated "return > 0;". I guess we could add an ifndef CONFIG_SMP check to the function and return 0 right away. That would eliminate any overhead in fault_mutex_hash(). > > > It wasn't merged before, but I don't recall the reasons > > why. So I've forward ported the patch (will send once everyone agrees that the matter is settled), including the changes Anton Blanchard added a exactly two years ago: https://lkml.org/lkml/2011/7/15/31 My tests show that the number of lock contentions drops from ~11k to around 500. So this approach alleviates a lot of the bottleneck. I've also ran it against libhugetlbfs without any regressions. Thanks, Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>