On Tue, Oct 4, 2016 at 12:06 PM, Davidlohr Bueso <dave@xxxxxxxxxxxx> wrote: > On Thu, 18 Aug 2016, Waiman Long wrote: > >> The osq_lock() and osq_unlock() function may not provide the necessary >> acquire and release barrier in some cases. This patch makes sure >> that the proper barriers are provided when osq_lock() is successful >> or when osq_unlock() is called. > > > But why do we need these guarantees given that osq is only used internally > for lock owner spinning situations? Leaking out of the critical region will > obviously be bad if using it as a full lock, but, as is, this can only hurt > performance of two of the most popular locks in the kernel -- although yes, > using smp_acquire__after_ctrl_dep is nicer for polling. > > If you need tighter osq for rwsems, could it be refactored such that mutexes > do not take a hit? I agree with David, the OSQ is meant to be used internally as a queuing mechanism than as something for protecting critical regions, and so these guarantees of preventing critical section leaks don't seem to be necessary for the OSQ. If that is the case, then it would be better to avoid the performance hit to mutexes and rwsems. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
