linux-kernel - Re: [PATCH-tip v3 02/14] locking/rwsem: Make owner available even if !CONFIG_RWSEM_SPIN_ON

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190416075313.GA34215@gmail.com>
Date:   Tue, 16 Apr 2019 09:53:13 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Waiman Long <longman@...hat.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Davidlohr Bueso <dave@...olabs.net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        huang ying <huang.ying.caritas@...il.com>
Subject: Re: [PATCH-tip v3 02/14] locking/rwsem: Make owner available even if
 !CONFIG_RWSEM_SPIN_ON_OWNER


* Waiman Long <longman@...hat.com> wrote:

> > It can be seen that a lot more readers got the lock via optimistic
> > spinning.  One possibility is that reader optimistic spinning causes
> > readers to spread out into more lock acquisition groups than without. The
> > K3 results show that grouping more readers into one lock acquisition
> > group help to improve performance for this microbenchmark. I will need
> > to run more tests to find out the root cause of this regression. It is
> > not an easy problem to solve.
> 
> Just an update on my will-it-scale regression investigation. I have
> tried various ways to tune the rwsem code to get more performance out
> from this benchmark. I got some minor improvements but nothing major. So
> it looks like that there are some workloads that have performance hurted
> by reader optimistic spinning and this benchmark is one of them. Now I
> am testing an adaptive reader optimistic spinning disabling patch that
> shows great promise as I was able to bring back a major portion of the
> lost performance. I will try to make the patch more aggressive to see if
> it can bring most of the lost performance back.

Thank you!

I've applied your two latest patches to WIP.locking/core as well, to keep 
it all tested and to see whether there's any other regressions. It's all 
looking good so far in my dogfood testing.

Thanks,

	Ingo