On Thu, Jun 18, 2015 at 03:20:22AM +0100, Waiman Long wrote: > The qrwlock is fair in the process context, but becoming unfair when > in the interrupt context to support use cases like the tasklist_lock. > > The current code isn't that well-documented on what happens when > in the interrupt context. The rspin_until_writer_unlock() will only > spin if the writer has gotten the lock. If the writer is still in the > waiting state, the increment in the reader count will cause the writer > to remain in the waiting state and the new interrupt context reader > will get the lock and return immediately. The current code, however, > do an additional read of the lock value which is not necessary as > the information have already been there in the fast path. This may > sometime cause an additional cacheline transfer when the lock is > highly contended. > > This patch passes the lock value information gotten in the fast path > to the slow path to eliminate the additional read. It also document > the action for the interrupt context readers more clearly. > > Signed-off-by: Waiman Long <Waiman.Long@xxxxxx> > --- > include/asm-generic/qrwlock.h | 4 ++-- > kernel/locking/qrwlock.c | 13 +++++++------ > 2 files changed, 9 insertions(+), 8 deletions(-) LGTM: Reviewed-by: Will Deacon <will.deacon@xxxxxxx> Will -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
