Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754397AbcJDV3D (ORCPT ); Tue, 4 Oct 2016 17:29:03 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:33731 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752268AbcJDV3B (ORCPT ); Tue, 4 Oct 2016 17:29:01 -0400 MIME-Version: 1.0 In-Reply-To: <20161004190601.GD24086@linux-80c1.suse> References: <1471554672-38662-1-git-send-email-Waiman.Long@hpe.com> <1471554672-38662-2-git-send-email-Waiman.Long@hpe.com> <20161004190601.GD24086@linux-80c1.suse> From: Jason Low Date: Tue, 4 Oct 2016 14:28:59 -0700 X-Google-Sender-Auth: UnWPd0VG94I7gOCGS4EbUNXovrc Message-ID: Subject: Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier To: Davidlohr Bueso Cc: Waiman Long , Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List , x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, Jason Low , Dave Chinner , Jonathan Corbet , Scott J Norton , Douglas Hatch , jason.low2@hpe.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1182 Lines: 25 On Tue, Oct 4, 2016 at 12:06 PM, Davidlohr Bueso 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