Re: [PATCH 0/8] sched: Fix hot-unplug regressions

From: Peter Zijlstra
Date: Sat Jan 16 2021 - 13:54:02 EST


On Sat, Jan 16, 2021 at 07:45:42AM -0800, Paul E. McKenney wrote:
> On Sat, Jan 16, 2021 at 04:25:58PM +0100, Peter Zijlstra wrote:
> > On Sat, Jan 16, 2021 at 12:30:33PM +0100, Peter Zijlstra wrote:
> > > Hi,
> > >
> > > These patches (no longer 4), seems to fix all the hotplug regressions as per
> > > nearly a 100 18*SRCU-P runs over-night.
> > >
> > > I did clean up the patches, so possibly I wrecked it again. I've started new
> > > runs and will again leave them running over-night.
> >
> > Hurph... I've got one splat from this version, one I've not seen before:
> >
> > [ 68.712848] Dying CPU not properly vacated!
> > ...
> > [ 68.744448] CPU1 enqueued tasks (2 total):
> > [ 68.745018] pid: 14, name: rcu_preempt
> > [ 68.745557] pid: 18, name: migration/1
> >
> > Paul, rcu_preempt, is from rcu_spawn_gp_kthread(), right? Afaict that
> > doesn't even have affinity.. /me wonders HTH that ended up on the
> > runqueue so late.
>
> Yes, rcu_preempt is from rcu_spawn_gp_kthread(), and you are right that
> the kernel code does not bind it anywhere. If this is rcutorture,
> there isn't enough of a userspace to do the binding there, eihter.
> Wakeups for the rcu_preempt task can happen in odd places, though.
>
> Grasping at straws...

My current straw is that the wakeup lands on the wakelist before ttwu()
will refuse to wake to the CPU, and then lands on the RQ after we've
waited. Which seems near impossible..

I'll keep staring..