From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <longman@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH] locking/rwsem: Make owner store task pointer of last owning reader
Date: Mon, 10 Sep 2018 11:31:56 +0200 [thread overview]
Message-ID: <20180910093156.GS24082@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <1536265114-10842-1-git-send-email-longman@redhat.com>
On Thu, Sep 06, 2018 at 04:18:34PM -0400, Waiman Long wrote:
> Currently, when a reader acquires a lock, it only sets the
> RWSEM_READER_OWNED bit in the owner field. The other bits are simply
> not used. When debugging hanging cases involving rwsems and readers,
> the owner value does not provide much useful information at all.
>
> This patch modifies the current behavior to always store the task_struct
> pointer of the last rwsem-acquiring reader in a reader-owned rwsem. This
> may be useful in debugging rwsem hanging cases especially if only one
> reader is involved. However, the task in the owner field may not the
> real owner or one of the real owners at all when the owner value is
> examined, for example, in a crash dump. So it is just an additional
> hint about the past history.
>
> If CONFIG_DEBUG_RWSEMS is enabled, the owner field will be checked at
> unlock time too to make sure the task pointer value is valid. That does
> have a slight performance cost and so is only enabled as part of that
> debug option.
>
> From the performance point of view, it is expected that the changes
> shouldn't have any noticeable performance impact. A rwsem microbenchmark
> (with 48 worker threads and 1:1 reader/writer ratio) was ran on a
> 2-socket 24-core 48-thread Haswell system. The locking rates on a
> 4.19-rc1 based kernel were as follows:
>
> 1) Unpatched kernel: 543.3 kops/s
> 2) Patched kernel: 549.2 kops/s
> 3) Patched kernel (CONFIG_DEBUG_RWSEMS on): 546.6 kops/s
>
> There was actually a slight increase in performance (1.1%) in this
> particular case. Maybe it was caused by the elimination of a branch or
> just a testing noise. Turning on the CONFIG_DEBUG_RWSEMS option also
> had less than the expected impact on performance.
>
> The least significant 2 bits of the owner value are now used to designate
> the rwsem is readers owned and the owners are anonymous.
So no immediate objection; but I'm still hoping to some day rewrite the
whole rwsem thing along the lines we did mutex and merge the 'count' and
'owner' fields into one.
[ RT has something along those lines, and I have half a patch that
starts doing that too, but I never found enough time to really work on
it :-( ]
Anyway, when we do something like that, this goes out the window of
course.
next prev parent reply other threads:[~2018-09-10 9:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 20:18 [PATCH] locking/rwsem: Make owner store task pointer of last owning reader Waiman Long
2018-09-10 9:31 ` Peter Zijlstra [this message]
2018-09-10 15:01 ` Waiman Long
2018-09-10 17:15 ` Davidlohr Bueso
2018-09-10 17:35 ` Waiman Long
2018-09-11 8:17 ` Peter Zijlstra
2018-09-11 12:56 ` Waiman Long
2018-09-11 19:21 ` Davidlohr Bueso
2018-09-11 19:38 ` Peter Zijlstra
2018-09-10 10:54 ` [tip:locking/core] " tip-bot for Waiman Long
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=20180910093156.GS24082@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dave@stgolabs.net \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=will.deacon@arm.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.