Messages in this thread | | | Date | Mon, 3 May 2021 21:17:17 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 04/19] sched: Prepare for Core-wide rq->lock |
| |
On Thu, Apr 29, 2021 at 01:11:54PM -0700, Josh Don wrote: > On Wed, Apr 28, 2021 at 2:13 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Tue, Apr 27, 2021 at 04:30:02PM -0700, Josh Don wrote: > > > > > Also, did you mean to have a preempt_enable_no_resched() rather than > > > prempt_enable() in raw_spin_rq_trylock? > > > > No, trylock really needs to be preempt_enable(), because it can have > > failed, at which point it will not have incremented the preemption count > > and our decrement can hit 0, at which point we really should reschedule. > > Ah yes, makes sense. Did you want to use preempt_enable_no_resched() > at all then? No chance of preempt_count() being 1 at the point of > enable, as you comment below.
preempt_enable_no_resched() avoids the branch which we know we'll never take. It generates slightly saner code. It's not much, but every little bit helps, right? ;-)
> > ( I'm suffering a cold and am really quite slow atm ) > > No worries, hope it's a mild one.
It's not the super popular one from '19, and the family seems to be mostly recovered again, so all's well.
> > How's this then? > > Looks good to me (other than the synchronize_sched()->synchronize_rcu()). > > For these locking patches, > Reviewed-by: Josh Don <joshdon@google.com>
Thanks!, I'll go fold them into the proper place and update the repo.
| |