From: Ingo Molnar <mingo@kernel.org>
To: Michel Lespinasse <walken@google.com>
Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>
Subject: Re: [PATCH] rwsem-spinlock: let rwsem write lock stealable
Date: Thu, 31 Jan 2013 14:10:32 +0100 [thread overview]
Message-ID: <20130131131032.GA6627@gmail.com> (raw)
In-Reply-To: <CANN689GwGh2sHwoP66JjoXs2ZMQAXbVpA0MHQahWq5M+baNfSQ@mail.gmail.com>
* Michel Lespinasse <walken@google.com> wrote:
> On Wed, Jan 30, 2013 at 1:14 AM, Yuanhan Liu
> <yuanhan.liu@linux.intel.com> wrote:
> > We(Linux Kernel Performance project) found a regression introduced by
> > commit 5a50508, which just convert all mutex lock to rwsem write lock.
> > The semantics is same, but the results is quite huge in some cases.
> > After investigation, we found the root cause: mutex support lock
> > stealing. Here is the link for the detailed regression report:
> > https://lkml.org/lkml/2013/1/29/84
> >
> > Ingo suggests to add write lock stealing to rwsem as well:
> > "I think we should allow lock-steal between rwsem writers - that
> > will not hurt fairness as most rwsem fairness concerns relate to
> > reader vs. writer fairness"
> >
> > I then tried it with rwsem-spinlock first as I found it much easier to
> > implement it than lib/rwsem.c. And here I sent out this patch first for
> > comments. I'd try lib/rwsem.c later once the change to rwsem-spinlock
> > is OK to you guys.
>
> I noticed that you haven't modified __down_write_trylock() - for
> consistency with __down_write() you should replace
> if (sem->activity == 0 && list_empty(&sem->wait_list)) {
> with
> if (sem->activity == 0) {
>
> Other than that, I like the idea. I was originally
> uncomfortable with doing lock stealing for the rwsem, but I
> think doing it for writers only as you propose should be fine.
> Readers wait for any queued writers, and in exchange they are
> guaranteed to get the lock once they've blocked. You *still*
> want to check for regressions that this change might cause -
> not with anon_vma as this was a mutex not long ago, but
> possibly with mmap_sem - but I'm crossing my fingers and
> thinking that it'll most likely turn out fine.
My gut feeling, from having implemented lock stealing in a
number of locking primitives in the past, is that writer
lock-stealing will be a measurable win for mmap_sem as well.
Thanks,
Ingo
prev parent reply other threads:[~2013-01-31 13:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-30 9:14 [PATCH] rwsem-spinlock: let rwsem write lock stealable Yuanhan Liu
2013-01-31 9:39 ` Ingo Molnar
2013-01-31 10:09 ` Yuanhan Liu
2013-01-31 10:45 ` Ingo Molnar
2013-01-31 12:23 ` Yuanhan Liu
2013-01-31 11:57 ` Michel Lespinasse
2013-01-31 12:40 ` Yuanhan Liu
2013-01-31 13:12 ` Ingo Molnar
2013-01-31 14:36 ` Yuanhan Liu
2013-01-31 21:18 ` Ingo Molnar
2013-02-01 2:16 ` Yuanhan Liu
2013-01-31 13:10 ` Ingo Molnar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130131131032.GA6627@gmail.com \
--to=mingo@kernel.org \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=walken@google.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.