Messages in this thread | | | Date | Wed, 19 Dec 2012 20:14:36 +0100 | From | Oleg Nesterov <> | Subject | Re: [RFC PATCH v4 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context |
| |
On 12/19, Srivatsa S. Bhat wrote: > > BTW, there is a small problem with the synchronize_sched() approach: > We can't generalize the synchronization scheme as a generic percpu rwlock > because the writer's role is split into 2, the first part (the one having > synchronize_sched()) which should be run in process context, and the > second part (the rest of it), which can be run in atomic context.
Yes,
> That is, needing the writer to be able to sleep (due to synchronize_sched()) > will make the locking scheme unusable (in other usecases) I think. And > the split (blocking and non-blocking part) itself seems hard to express > as a single writer API.
I do not think this is the problem.
We need 2 helpers for writer, the 1st one does synchronize_sched() and the 2nd one takes rwlock. A generic percpu_write_lock() simply calls them both.
In fact I think that the 1st helper should not do synchronize_sched(), and (say) cpu_hotplug_begin() should call it itself. Because if we also change cpu_hotplug_begin() to use percpu_rw_sem we do not want to do synchronize_sched() twice. But lets ignore this for now.
But,
> Hmmm.. so what do we do? Shall we say "We anyway have to do smp_rmb() in the > reader in the fast path. Instead let's do a full smp_mb() and get rid of > the synchronize_sched() in the writer, and thereby expose this synchronization > scheme as generic percpu rwlocks?" Or should we rather use synchronize_sched() > and keep this synchronization scheme restricted to CPU hotplug only?
Oh, I do not know ;)
To me, the main question is: can we use synchronize_sched() in cpu_down? It is slow.
Oleg.
| |