Messages in this thread | | | Date | Mon, 10 Dec 2012 18:28:59 +0100 | From | Oleg Nesterov <> | Subject | Re: [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context |
| |
On 12/10, Srivatsa S. Bhat wrote: > > On 12/10/2012 02:43 AM, Oleg Nesterov wrote: > > Damn, sorry for noise. I missed this part... > > > > On 12/10, Srivatsa S. Bhat wrote: > >> > >> On 12/10/2012 12:44 AM, Oleg Nesterov wrote: > >>> the latency. And I guess something like kick_all_cpus_sync() is "too heavy". > >> > >> I hadn't considered that. Thinking of it, I don't think it would help us.. > >> It won't get rid of the currently running preempt_disable() sections no? > > > > Sure. But (again, this is only my feeling so far) given that get_online_cpus_atomic() > > does cli/sti, > > Ah, that one! Actually, the only reason I do that cli/sti is because, potentially > interrupt handlers can be hotplug readers too. So we need to protect the portion > of the code of get_online_cpus_atomic() which is not re-entrant.
Yes, I understand.
> > this can help to implement ensure-the-readers-must-see-the-pending-writer. > > IOW this might help to implement sync-with-readers. > > > > 2 problems: > > 1. It won't help with cases like this: > > preempt_disable() > ... > preempt_disable() > ... > <------- Here > ... > preempt_enable() > ... > preempt_enable()
No, I meant that kick_all_cpus_sync() can be used to synchronize with cli/sti in get_online_cpus_atomic(), just like synchronize_sched() does in the code I posted a minute ago.
> 2. Part of the reason we want to get rid of stop_machine() is to avoid the > latency it induces on _all_ CPUs just to take *one* CPU offline. If we use > kick_all_cpus_sync(), we get into that territory again : we unfairly interrupt > every CPU, _even when_ that CPU's existing preempt_disabled() sections might > not actually be hotplug readers! (ie., not bothered about CPU Hotplug).
I agree, that is why I said it is "too heavy".
Oleg.
| |