Messages in this thread Patch in this message | | | Date | Wed, 8 Dec 2021 11:03:57 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] use x86 cpu park to speedup smp_init in kexec situation |
| |
On Wed, Dec 08, 2021 at 06:32:15PM +0000, David Woodhouse wrote: > On Wed, 2021-12-08 at 09:35 -0800, Paul E. McKenney wrote: > > On Wed, Dec 08, 2021 at 04:57:07PM +0000, David Woodhouse wrote: > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > index ef8d36f580fc..544198c674f2 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -4246,11 +4246,11 @@ void rcu_cpu_starting(unsigned int cpu) > > > > > > rnp = rdp->mynode; > > > mask = rdp->grpmask; > > > + raw_spin_lock_irqsave_rcu_node(rnp, flags); > > > > If I am not too confused this morning, this can result in confusing > > lockdep splats because lockdep needs RCU to be watching the CPU > > acquiring the lock. See the rcu_lockdep_current_cpu_online() > > function and is callers, with emphasis on lockdep_rcu_suspicious() > > and rcu_read_lock_held_common(). > > Hm, OK. And it is the very act of setting rnp->ofl_seq & 1 which > triggers that, yes?
Prevents that from triggering, but if I recall correctly, yes.
> > > WRITE_ONCE(rnp->ofl_seq, rnp->ofl_seq + 1); > > > WARN_ON_ONCE(!(rnp->ofl_seq & 0x1)); > > > rcu_dynticks_eqs_online(); > > > smp_mb(); // Pair with rcu_gp_cleanup()'s ->ofl_seq barrier(). > > > - raw_spin_lock_irqsave_rcu_node(rnp, flags); > > > > > > WRITE_ONCE(rnp->qsmaskinitnext, rnp->qsmaskinitnext | mask); > > > newcpu = !(rnp->expmaskinitnext & mask); > > > rnp->expmaskinitnext |= mask; > > > @@ -4261,6 +4261,11 @@ void rcu_cpu_starting(unsigned int cpu) > > > rdp->rcu_onl_gp_seq = READ_ONCE(rcu_state.gp_seq); > > > rdp->rcu_onl_gp_flags = READ_ONCE(rcu_state.gp_flags); > > > > > > + smp_mb(); // Pair with rcu_gp_cleanup()'s ->ofl_seq barrier(). > > > + WRITE_ONCE(rnp->ofl_seq, rnp->ofl_seq + 1); > > > + WARN_ON_ONCE(rnp->ofl_seq & 0x1); > > > + smp_mb(); /* Ensure RCU read-side usage follows above initialization. */ > > > + > > > /* An incoming CPU should never be blocking a grace period. */ > > > if (WARN_ON_ONCE(rnp->qsmask & mask)) { /* RCU waiting on incoming CPU? */ > > > rcu_disable_urgency_upon_qs(rdp); > > > @@ -4269,10 +4274,6 @@ void rcu_cpu_starting(unsigned int cpu) > > > } else { > > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > > > And ditto here upon release. > > > > As a short-term hack, I suggest moving the ->ofl_seq field from the > > rcu_node structure to the rcu_data structure. This will require the loop > > in rcu_gp_init() to wait on each of the current rcu_node structure's CPUs. > > Which is not good from the viewpoint of the RCU grace-period kthread's > > CPU consumption, but it should allow you to make progress on your testing. > > Ok, thanks. My initial hack of sticking my own spinlock around the > whole thing was also working for testing, but now I'm trying to clean > it up so I can post something for merging.
Sounds good!
You know, maybe it would be way easier to just create a new spinlock and use arch_spin_lock() to acquire it and arch_spin_unlock() to release it, bypassing lockdep for that one lock. Then proceed as in your initial patch.
> > Though I are having some difficulty remembering why that wait loop in > > rcu_gp_init() needs to be there. I am going to try removing it and > > seeing if rcutorture will be kind enough to remind me. ;-) > > > > And it will of course be necessary to upgrade rcutorture to test > > concurrent CPU-online operations. Will there be some sort of > > start-CPU-online function, or should I instead expect to need to > > provide multiple kthreads for onlining and an additional kthread > > for offliing? > > This is just at *boot* time, not runtime hotplug/unplug. We observed > that we spend quite a lot of time on a 96-way 2-socket Skylake system > just sending INIT to each CPU in turn, then waiting for it to be fully > online, then moving on to the next one. Hence doing them all in > parallel, which reduces the AP bringup time from about 300ms to 30ms. > > https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/parallel-5.16
Nice win!!!
And I do understand that you are only worried about boot speed, but adequate stress-testing of this will require run-time exercising of this. Yes, 30ms is fast, but you have other overheads when repeatedly rebooting, and so doing runtime tests will find bugs faster.
> > Huh. I take it that concurrent online and offline is future work? > > Or does that need to work initially? > > Concurrent *online* (at boot) is the whole point. Those last two > commits currently in the branch linked above are the "oh crap, *that* > part doesn't work if you really let it happen concurrently, so let's > serialize them" hacks. In particular, the RCU one is > https://git.infradead.org/users/dwmw2/linux.git/commitdiff/5f4b77c9459c > > And now I'm trying to come up with something a little less hackish :)
Understood! I am just trying to work out a decent validation plan for this. Let's just say that changes in this area have not traditionally been boring. ;-)
> > More to the point, what are you using to stress-test this capability? > > Just boot. With lots of CPUs (and vCPUs in qemu, but even with a nice > fast parallel CPU bringup, Linux then spends the next 16 seconds > printing silly pr_info messages about KVM features so it isn't the most > exciting overall result right now) > > I confess I haven't actually tested runtime hotplug/unplug again > recently. I should do that ;)
The rcutorture TREE03 scenario is rather aggressive about this. From the root of a recent Linux-kernel source tree:
tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 1h configs "TREE03" --trust-make Or, if you have a 64-CPU system:
tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 1h configs "4*TREE03" --trust-make
The latter would be a semi-credible smoke test for this sort of change.
Thanx, Paul
| |