On Mon, Dec 13, 2021 at 12:30:59PM +0530, Neeraj Upadhyay wrote: > To support onlining multiple CPUs concurrently, > change rcu_state.n_online_cpus updates to be atomic. > Note, it's ok for rcu_blocking_is_gp() to do a > atomic_read(&rcu_state.n_online_cpus), as the > value of .n_online_cpus switches from 1->2, in > rcutree_prepare_cpu(), which runs before the new > CPU comes online. Similarly 2->1 transition happens > from rcutree_dead_cpu(), which executes after the > CPU is offlined, and runs on the last online CPU. > > Signed-off-by: Neeraj Upadhyay <quic_neeraju@xxxxxxxxxxx> That's a step but I can imagine much more complications to handle while looking at rcutree_dead_cpu() VS rcutree_dead_cpu() (or other hotplug operations) inside the same rnp calling rcu_boost_kthread_setaffinity() concurrently or more generally rcu_boost_kthread_setaffinity() against concurrent onlining/offlining. This function fetches the online CPUs to decide the affinity of boosting. This can go quite wrong if CPUs can be concurrently onlined/offlined. And I don't know how such problems are going to be solved in the future but some new CPU hotplug concurrency primitives will be needed... That's one more reason why I think it is a bit early to handle this wide problem... Thanks.
