[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 1/4] xen/rcu: don't use stop_machine_run() for rcu_barrier()
On 13.03.2020 12:18, Jürgen Groß wrote: > On 13.03.20 12:02, Julien Grall wrote: >> On 12/03/2020 08:28, Juergen Gross wrote: >>> + for ( ;; ) >>> + { >>> + if ( !atomic_read(&pending_count) && get_cpu_maps() ) >>> + { >>> + n_cpus = num_online_cpus(); >>> + >>> + if ( atomic_cmpxchg(&pending_count, 0, n_cpus + 1) == 0 ) >>> + break; >>> + >>> + put_cpu_maps(); >>> + } >>> + >>> + process_pending_softirqs(); >>> + cpu_relax(); >>> + } >>> + >>> + atomic_set(&cpu_count, n_cpus); >>> + cpumask_raise_softirq(&cpu_online_map, RCU_SOFTIRQ); >>> + >>> + put_cpu_maps(); >> >> If you put the CPU maps, wouldn't it be possible to have a CPU turned >> off? If not, can you add a comment in the code why this is safe? > > Yes, you are right. This might be possible, even if rather > unlikely as a cpu being removed has to be in idle already, so > the pending softirq should be picked up rather fast. I think that's not the main aspect. The CPU to be removed may already be spinning in cpu_hotplug_begin() (and may in particular also already be past the rcu_barrier() that Igor's patch is going to put there). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |