Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1019680ybl; Fri, 31 Jan 2020 12:24:18 -0800 (PST) X-Google-Smtp-Source: APXvYqzsi/I8USpVwF8a/RMasdTsVyOludHPdMqqF8FF2CZ50SfbL7uhzTKq+L45uQ5i+EmooJnl X-Received: by 2002:a05:6830:200d:: with SMTP id e13mr8993683otp.364.1580502257931; Fri, 31 Jan 2020 12:24:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580502257; cv=none; d=google.com; s=arc-20160816; b=nPeyMbxhvsR8L/vVEEanJ//mwF5h8HE3qNgdcf1nnGfgRJ/4v05qUWw1sBawGtA3Kv JiawFGpkXik4EkDm7cxoqK6DvNBz7mLk0YolfHvJrD4cjiAd1MM75cv9APpdKGicI+U7 +y1UiWvpf0njuFc2OrVB6TR4Y45cbevc4nakLhgMooc0a6314au0F2e+tjJSFxZgzQXQ 1ACBwo2DqVIsQrmNE9jlk3cJNhxsi8fk0zIIn9PGUHeZr8RY5xxgL0+s6Z6I7hg1dPk3 ahCJYpMf4Ibxe0c7qr/EeT2W5zSAJMot9tkUuoqSz5+PH1lQRL+5IjkmgfxiWfeMuExW wDPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=8VDDLL9Olk0t3c9bXt+Vf8v5lV0j7Xl+ddOvLr8bFgU=; b=PJqUObWYwVV/XxODBSxMgwAwIZnwUR1I8hV3KullKnTtGeZXoj9DFIFyUNtP1LJYqk eza8V8XwkQEDdt/3xOE6HKh7zEBf9T8nPtfdVouychVM15wV3TNT+hmt45/2RCEVf8yN wmo10B947IDbB0aMvyRndP6Mh0Gru5Pxq/S96aUHU7497pZZ8pWIgIrEvbwZkpTYFaYB ElAHid9/qnHAyKPbM9n9vZ5iIakPWQSNtrlfplC9kEfhRAM0IiwH78uqFkKKUWX5eVKg qgLGMLQF53gS0Doxax/AnbxG/0ADuNmwaUWDbN0fUY4XR6F8M1U7ljh+wDMbAqKPV+0v aFtg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i5si4939120oif.211.2020.01.31.12.24.05; Fri, 31 Jan 2020 12:24:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726109AbgAaUXP (ORCPT + 99 others); Fri, 31 Jan 2020 15:23:15 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:56626 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbgAaUXO (ORCPT ); Fri, 31 Jan 2020 15:23:14 -0500 Received: from 51.26-246-81.adsl-static.isp.belgacom.be ([81.246.26.51] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ixcol-0004uw-36; Fri, 31 Jan 2020 21:23:07 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id BBC1A105BDC; Fri, 31 Jan 2020 21:23:01 +0100 (CET) From: Thomas Gleixner To: Davidlohr Bueso , Alex Shi Cc: Peter Zijlstra , Ingo Molnar , Will Deacon , linux-kernel@vger.kernel.org Subject: Re: [PATCH] locking/rtmutex: remove unused cmpxchg_relaxed In-Reply-To: <20200131173922.hjvugxuybrn2wbsn@linux-p48b> References: <1579595686-251535-1-git-send-email-alex.shi@linux.alibaba.com> <20200131173922.hjvugxuybrn2wbsn@linux-p48b> Date: Fri, 31 Jan 2020 21:23:01 +0100 Message-ID: <87r1zfxtne.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Davidlohr Bueso writes: > On Tue, 21 Jan 2020, Alex Shi wrote: Subject: locking/rtmutex: remove unused cmpxchg_relaxed should be Subject: locking/rtmutex: Remove unused rt_mutex_cmpxchg_relaxed() You're not removing cmpxchg_relaxed, right? >> No one use this macro after it was introduced. Better to remove it? Please make that factual. The macro was never used at all. Remove it. > You also need to remove it for the CONFIG_DEBUG_RT_MUTEXES=y case. Yes. > Hmm unrelated, but do we want CCAS for rtmutex fastpath? Ie: > > (l->owner == c && cmpxchg_acquire(&l->owner, c, n) == c) > > That would optimize for the contended case and avoid the cmpxchg - it would > also help if we ever do the top-waiter spin thing. Not sure if it buys much, but it kinda makes sense. Thanks, tglx