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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/