From: Ingo Molnar <mingo@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Davidlohr Bueso <dave@stgolabs.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Tim Chen <tim.c.chen@linux.intel.com>,
huang ying <huang.ying.caritas@gmail.com>
Subject: Re: [PATCH-tip v3 02/14] locking/rwsem: Make owner available even if !CONFIG_RWSEM_SPIN_ON_OWNER
Date: Fri, 12 Apr 2019 18:41:23 +0200 [thread overview]
Message-ID: <20190412164123.GA119547@gmail.com> (raw)
In-Reply-To: <277e9c8e-8913-b251-4c98-dd2d4997d643@redhat.com>
* Waiman Long <longman@redhat.com> wrote:
> > BTW, the v3 patch that I posted yesterday should work fine as long as
> > CONFIG_RWSEM_SPIN_ON_OWNER is defined.
> >
> > Cheers,
> > Longman
> >
> Oh, I see that the WIP.locking/core is currently merged into master. I
> would say rwsem part1 patchset and patch 1 of part2 are stable. So I
> would suggest merging those into the the master will be good. The rests
> are still under review until I get an OK from Peter. If they miss the
> next merge window and have to postpone to 5.3, I am fine with that.
So beyond the primary constraint of PeterZ OK-ing it all, there's also
these two scalability regression reports from the ktest bot:
[locking/rwsem] 1b94536f2d: stress-ng.bad-altstack.ops_per_sec -32.7% regression
[locking/rwsem] adc32e8877: will-it-scale.per_thread_ops -21.0% regression
Thanks,
Ingo
next prev parent reply other threads:[~2019-04-12 16:41 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 18:42 [PATCH-tip v3 00/14] locking/rwsem: Rwsem rearchitecture part 2 Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 01/14] locking/rwsem: Prevent unneeded warning during locking selftest Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 02/14] locking/rwsem: Make owner available even if !CONFIG_RWSEM_SPIN_ON_OWNER Waiman Long
2019-04-11 8:12 ` Peter Zijlstra
2019-04-11 16:03 ` Waiman Long
2019-04-12 7:02 ` Ingo Molnar
2019-04-12 7:05 ` Peter Zijlstra
2019-04-12 7:09 ` Ingo Molnar
2019-04-12 14:04 ` Waiman Long
2019-04-12 14:07 ` Waiman Long
2019-04-12 14:22 ` Waiman Long
2019-04-12 16:41 ` Ingo Molnar [this message]
2019-04-12 18:05 ` Waiman Long
2019-04-13 2:24 ` Waiman Long
2019-04-15 13:43 ` Waiman Long
2019-04-16 7:53 ` Ingo Molnar
2019-04-12 18:21 ` Peter Zijlstra
2019-04-10 18:42 ` [PATCH-tip v3 03/14] locking/rwsem: Implement a new locking scheme Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 04/14] locking/rwsem: Implement lock handoff to prevent lock starvation Waiman Long
2019-04-10 19:38 ` Peter Zijlstra
2019-04-10 20:28 ` Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 05/14] locking/rwsem: Remove rwsem_wake() wakeup optimization Waiman Long
2019-04-11 7:25 ` Peter Zijlstra
2019-04-11 15:55 ` Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 06/14] locking/rwsem: Make rwsem_spin_on_owner() return owner state Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 07/14] locking/rwsem: Ensure an RT task will not spin on reader Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 08/14] locking/rwsem: Wake up almost all readers in wait queue Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 09/14] locking/rwsem: Enable readers spinning on writer Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 10/14] locking/rwsem: Enable time-based spinning on reader-owned rwsem Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 11/14] locking/rwsem: Add more rwsem owner access helpers Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 12/14] locking/rwsem: Guard against making count negative Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 13/14] locking/rwsem: Merge owner into count on x86-64 Waiman Long
2019-04-10 18:42 ` [PATCH-tip v3 14/14] locking/rwsem: Remove redundant computation of writer lock word Waiman Long
2019-04-11 8:37 ` [PATCH-tip v3 00/14] locking/rwsem: Rwsem rearchitecture part 2 Peter Zijlstra
2019-04-11 16:09 ` 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=20190412164123.GA119547@gmail.com \
--to=mingo@kernel.org \
--cc=dave@stgolabs.net \
--cc=huang.ying.caritas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/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.