Received: by 10.192.165.148 with SMTP id m20csp959957imm; Sat, 5 May 2018 01:48:05 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq47oOXUR6e2AlVkvNOBauD5acMMCswBQooKK4V29AjfrXvJCphNBAAQY3DrAT6ySQ/VljX X-Received: by 2002:a63:18c:: with SMTP id 134-v6mr10863733pgb.138.1525510085492; Sat, 05 May 2018 01:48:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525510085; cv=none; d=google.com; s=arc-20160816; b=UaGeWK6tVEZRtwjyjL2n1odMz3DOCem4Jvlaxt11yYFIRgsVU3VSla/E8U+dkVRcjF u7bwmYpsTbLl5DTaiVp+ujOvlzhiEb670H6VTeazx+ihAXtvbx0NH//xyDLD/hvFTb8n ULsVr8caaPeufahRzbUXgjXO9qfGPFJsKp5fr5ydIkfrHTFSElFYLE6rUOE0THif17PW ke6o54ENjpIvnWfy0xC42rA2JbHxCHGUhPOOjgC94L95HM0N0v9g5wNUyAkd1zgWaFrk DvQaNBlUqbbwq+Ewp4kHpGg6NJaxywLhw4moP/yy6+vTDJ9sqpEfl2gSXlaNT8NGs4Wk O7eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=GRYCGFFFVDTo2pntpYajEewV3ru/0p+CrxW58PSod2U=; b=yGBI8mbP1aUuaCSaftfiH0hpIeGAZE5zwmBeWH5vsQfxg3iMZDPTnBj09PTuTVFdWU kGOCUIjNFHlassxhMMQiznHj7xAVhff74WTsIBWu+yElEn3lEkCJY4fs4SvbtcFYATIY YiSlsPQT/9bKwfzl4dZOXbOeGYAqPkw/4ovNjvHSpAw25CgsWcZc4schvpndWOo9qksG VZhRu/PmB/YIzmi2KmFEyqwCaHRfns5iDkJkukDwtFMIjN6STFTmiP9IwzFLHfXR+BTl SG1K0jNZ1EP8x9Z3T7c+1tdzUEJvSA40UdNWFlvA+SrzQPThpePNrcNFIS12QHZRG6jn MNHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=shcJ8eUu; 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 t29-v6si15053192pgo.539.2018.05.05.01.47.37; Sat, 05 May 2018 01:48:05 -0700 (PDT) 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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=shcJ8eUu; 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 S1751243AbeEEIr3 (ORCPT + 99 others); Sat, 5 May 2018 04:47:29 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:44804 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750971AbeEEIr1 (ORCPT ); Sat, 5 May 2018 04:47:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GRYCGFFFVDTo2pntpYajEewV3ru/0p+CrxW58PSod2U=; b=shcJ8eUudwzxgWi+7Omdnpb79 syEGjinG2LTSTxNcIH1Ve1Yh0acwZ3TKei66F5CrYRj8kzvViwKD/4U6YlZtw18Gj9tIQM/dzXNPv U8Ou6nF6bmFa8+2x2LL0A6U4MvVzBpkypFAscOcOwkgtf4SHOHwZi3FIj2pZs2ampZtY6gJcd+1Ny 9m15jPmRGGuH7QVFOCQvzdeY7rR6cn3iYS3QI+j22QBhVFR/tzLHjxjh7zp2kg82Pc3pBNJyjT7oI z8uQ7WHDPchK0h2T7MZ2cuOyzSE+wu090EZObqdrtSLY1s6Um7podxek70aeL+BXn3S0CVWsuC2Bw oLfp4GfLA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fEsqi-00009a-EG; Sat, 05 May 2018 08:47:24 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id C0678305175; Sat, 5 May 2018 10:47:22 +0200 (CEST) Date: Sat, 5 May 2018 10:47:22 +0200 From: Peter Zijlstra To: Ingo Molnar Cc: Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, aryabinin@virtuozzo.com, boqun.feng@gmail.com, catalin.marinas@arm.com, dvyukov@google.com, will.deacon@arm.com Subject: Re: [PATCH] locking/atomics: Clean up the atomic.h maze of #defines Message-ID: <20180505084721.GA32344@noisy.programming.kicks-ass.net> References: <20180504173937.25300-1-mark.rutland@arm.com> <20180504173937.25300-2-mark.rutland@arm.com> <20180504180105.GS12217@hirez.programming.kicks-ass.net> <20180504180909.dnhfflibjwywnm4l@lakrids.cambridge.arm.com> <20180505081100.nsyrqrpzq2vd27bk@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180505081100.nsyrqrpzq2vd27bk@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 05, 2018 at 10:11:00AM +0200, Ingo Molnar wrote: > Before: > > #ifndef atomic_fetch_dec_relaxed > > #ifndef atomic_fetch_dec > #define atomic_fetch_dec(v) atomic_fetch_sub(1, (v)) > #define atomic_fetch_dec_relaxed(v) atomic_fetch_sub_relaxed(1, (v)) > #define atomic_fetch_dec_acquire(v) atomic_fetch_sub_acquire(1, (v)) > #define atomic_fetch_dec_release(v) atomic_fetch_sub_release(1, (v)) > #else /* atomic_fetch_dec */ > #define atomic_fetch_dec_relaxed atomic_fetch_dec > #define atomic_fetch_dec_acquire atomic_fetch_dec > #define atomic_fetch_dec_release atomic_fetch_dec > #endif /* atomic_fetch_dec */ > > #else /* atomic_fetch_dec_relaxed */ > > #ifndef atomic_fetch_dec_acquire > #define atomic_fetch_dec_acquire(...) \ > __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__) > #endif > > #ifndef atomic_fetch_dec_release > #define atomic_fetch_dec_release(...) \ > __atomic_op_release(atomic_fetch_dec, __VA_ARGS__) > #endif > > #ifndef atomic_fetch_dec > #define atomic_fetch_dec(...) \ > __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__) > #endif > #endif /* atomic_fetch_dec_relaxed */ > > After: > > #ifndef atomic_fetch_dec_relaxed > # ifndef atomic_fetch_dec > # define atomic_fetch_dec(v) atomic_fetch_sub(1, (v)) > # define atomic_fetch_dec_relaxed(v) atomic_fetch_sub_relaxed(1, (v)) > # define atomic_fetch_dec_acquire(v) atomic_fetch_sub_acquire(1, (v)) > # define atomic_fetch_dec_release(v) atomic_fetch_sub_release(1, (v)) > # else > # define atomic_fetch_dec_relaxed atomic_fetch_dec > # define atomic_fetch_dec_acquire atomic_fetch_dec > # define atomic_fetch_dec_release atomic_fetch_dec > # endif > #else > # ifndef atomic_fetch_dec_acquire > # define atomic_fetch_dec_acquire(...) __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__) > # endif > # ifndef atomic_fetch_dec_release > # define atomic_fetch_dec_release(...) __atomic_op_release(atomic_fetch_dec, __VA_ARGS__) > # endif > # ifndef atomic_fetch_dec > # define atomic_fetch_dec(...) __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__) > # endif > #endif > > The new variant is readable at a glance, and the hierarchy of defines is very > obvious as well. It wraps and looks hideous in my normal setup. And I do detest that indent after # thing. > And I think we could do even better - there's absolutely no reason why _every_ > operation has to be made conditional on a finegrained level - they are overriden > in API groups. In fact allowing individual override is arguably a fragility. > > So we could do the following simplification on top of that: > > #ifndef atomic_fetch_dec_relaxed > # ifndef atomic_fetch_dec > # define atomic_fetch_dec(v) atomic_fetch_sub(1, (v)) > # define atomic_fetch_dec_relaxed(v) atomic_fetch_sub_relaxed(1, (v)) > # define atomic_fetch_dec_acquire(v) atomic_fetch_sub_acquire(1, (v)) > # define atomic_fetch_dec_release(v) atomic_fetch_sub_release(1, (v)) > # else > # define atomic_fetch_dec_relaxed atomic_fetch_dec > # define atomic_fetch_dec_acquire atomic_fetch_dec > # define atomic_fetch_dec_release atomic_fetch_dec > # endif > #else > # ifndef atomic_fetch_dec > # define atomic_fetch_dec(...) __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__) > # define atomic_fetch_dec_acquire(...) __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__) > # define atomic_fetch_dec_release(...) __atomic_op_release(atomic_fetch_dec, __VA_ARGS__) > # endif > #endif This would disallow an architecture to override just fetch_dec_release for instance. I don't think there currently is any architecture that does that, but the intent was to allow it to override anything and only provide defaults where it does not. None of this takes away the giant trainwreck that is the annotated atomic stuff though. And I seriously hate this one: ba1c9f83f633 ("locking/atomic/x86: Un-macro-ify atomic ops implementation") and will likely undo that the moment I need to change anything there. So no, don't like.