lkml.org 
[lkml]   [2013]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Performance regression from switching lock to rw-sem for anon-vma tree
From
Date
On Wed, 2013-06-19 at 16:11 -0700, Davidlohr Bueso wrote:
> On Mon, 2013-06-17 at 17:08 -0700, Tim Chen wrote:
> > On Mon, 2013-06-17 at 16:35 -0700, Davidlohr Bueso wrote:
> > > On Tue, 2013-06-18 at 07:20 +0800, Alex Shi wrote:
> > > > On 06/18/2013 12:22 AM, Davidlohr Bueso wrote:
> > > > > After a lot of benchmarking, I finally got the ideal results for aim7,
> > > > > so far: this patch + optimistic spinning with preemption disabled. Just
> > > > > like optimistic spinning, this patch by itself makes little to no
> > > > > difference, yet combined is where we actually outperform 3.10-rc5. In
> > > > > addition, I noticed extra throughput when disabling preemption in
> > > > > try_optimistic_spin().
> > > > >
> > > > > With i_mmap as a rwsem and these changes I could see performance
> > > > > benefits for alltests (+14.5%), custom (+17%), disk (+11%), high_systime
> > > > > (+5%), shared (+15%) and short (+4%), most of them after around 500
> > > > > users, for fewer users, it made little to no difference.
> > > >
> > > > A pretty good number. what's the cpu number in your machine? :)
> > >
> > > 8-socket, 80 cores (ht off)
> > >
> > >
> >
> > David,
> >
> > I wonder if you are interested to try the experimental patch below.
> > It tries to avoid unnecessary writes to the sem->count when we are
> > going to fail the down_write by executing rwsem_down_write_failed_s
> > instead of rwsem_down_write_failed. It should further reduce the
> > cache line bouncing. It didn't make a difference for my
> > workload. Wonder if it may help yours more in addition to the
> > other two patches. Right now the patch is an ugly hack. I'll merge
> > rwsem_down_write_failed_s and rwsem_down_write_failed into one
> > function if this approach actually helps things.
> >
>
> I tried this on top of the patches we've already been dealing with. It
> actually did more harm than good. Only got a slight increase in the
> five_sec workload, for the rest either no effect, or negative. So far
> the best results are still with spin on owner + preempt disable + Alex's
> patches.
>

Thanks for trying it out. A little disappointed as I was expecting no
change in performance for the worst case.

Tim



\
 
 \ /
  Last update: 2013-06-20 01:41    [W:0.070 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site