Messages in this thread | | | Date | Thu, 17 Aug 2017 07:13:04 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH v5 tip/core/rcu 4/9] completion: Replace spin_unlock_wait() with lock/unlock pair |
| |
On Thu, Aug 17, 2017 at 02:49:09PM +0200, Ingo Molnar wrote: > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > > this change - or can I pick this up into the scheduler tree? > > > > Timely question! ;-) > > > > My current plan is to send you a pull request like the following later > > today, Pacific Time (but rebased adding Steve Rostedt's Reviewed-by). > > This patch is on one of the branches, currently v4.13-rc2..93d8d7a12090 > > ("arch: Remove spin_unlock_wait() arch-specific definitions") in my > > -rcu tree. > > > > Ah, and v4.13-rc2..7391304c4959 ("membarrier: Expedited private command") > > is mostly outside of RCU as well. > > > > Since I will be rebasing and remerging anyway, if you would prefer that I > > split the spin_unlock_wait() and/or misc branches out, I am happy to do so. > > If I don't hear otherwise, though, I will send all seven branches using > > my usual approach. > > > > So, if you want something different than my usual approach, please just > > let me know! > > No, all branches together sounds good to me!
Very good, will do!
> If you are rebasing anyway, here are some (very minor) commit title nits I noticed: > > > swait: add idle variants which don't contribute to load average > > rcu: use idle versions of swait to make idle-hack clear > > Capitalization.
Will fix! Believe it or not, I looked for these... :-/
> > membarrier: Expedited private command > > Should start with a verb.
OK, something like "Provide expedited private command".
> > doc: RCU documentation update > > doc: Update RCU documentation > > ?
Works for me!
> > doc: No longer allowed to use rcu_dereference on non-pointers > > doc: Describe that it is no longer allowed to use rcu_dereference() on non-pointers > > ?
Will add a real commit log.
> > torture: Add --kconfig argument to kvm.sh > > rcutorture: Don't wait for kernel when all builds fail > > Is there a difference between 'torture: ' and 'rcutorture: ' prefixes?
Yes, rcutorture is specific to RCU, while torture would also affect locktorture.
Ah, and if I am delaying the cond_resched() patch, I need to retest, which means I will send you the pull request tomorrow or Monday, depending on how the testing goes.
Thanx, Paul
> Thanks, > > Ingo >
| |