lkml.org 
[lkml]   [2013]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm/hugetlb: per-vma instantiation mutexes
From
Date
On Mon, 2013-07-15 at 16:08 -0700, Andrew Morton wrote:
> On Mon, 15 Jul 2013 17:24:32 +1000 David Gibson <david@gibson.dropbear.id.au> 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



\
 
 \ /
  Last update: 2013-07-16 02:21    [W:0.110 / U:9.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site