From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754004AbbI2U6q (ORCPT ); Tue, 29 Sep 2015 16:58:46 -0400 Received: from www.linutronix.de ([62.245.132.108]:47857 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752338AbbI2U6h (ORCPT ); Tue, 29 Sep 2015 16:58:37 -0400 Date: Tue, 29 Sep 2015 22:57:32 +0200 (CEST) From: Thomas Gleixner To: Davidlohr Bueso cc: Peter Zijlstra , Ingo Molnar , Andrew Morton , Linus Torvalds , Will Deacon , "Paul E. McKenney" , linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH v2] locking/rtmutex: Use acquire/release semantics In-Reply-To: <20150928194948.GA4035@linux-uzut.site> Message-ID: References: <1442866676-10359-1-git-send-email-dave@stgolabs.net> <1442866676-10359-4-git-send-email-dave@stgolabs.net> <20150924010642.GB10657@linux-uzut.site> <20150928194948.GA4035@linux-uzut.site> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 28 Sep 2015, Davidlohr Bueso wrote: > On Sun, 27 Sep 2015, Thomas Gleixner wrote: > > That changelog is not really helpful if someone is going to look at it > > half a year from now who doesn't have the background of the discussion > > leading to these changes. > > Ok, how does the following sound? > > "" > As of 654672d4ba1 (locking/atomics: Add _{acquire|release|relaxed}() variants > of some atomic operations) and 6d79ef2d30e (locking, asm-generic: Add > _{relaxed|acquire|release}() variants for 'atomic_long_t'), weakly ordered > archs can benefit from more relaxed use of barriers when locking and > unlocking, > instead of regular full barrier semantics. While currently only arm64 supports > such optimizations, updating corresponding locking primitives serves for other > archs to immediately benefit as well, once the necessary machinery is > implemented > of course. > "" > > It's not _that_ different from the original changelong, but it should allow > future readers to at least be able to easily see the context of where the > changes come from. I don't think it's of much use going into the actual code > changes as they are pretty obvious -- and the ones that aren't (ie relaxed) > have the justification in the comments. Ok, care to resend the whole thing? Thanks, tglx