Received: by 10.192.165.148 with SMTP id m20csp975968imm; Sat, 5 May 2018 02:06:39 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpLcUmhoWoL5gFTn/SvwdPDGeBRaTJgZVXOUzacijsRV+5oOoIU5MceXOfs2gJ/q3NX8QuV X-Received: by 10.98.150.92 with SMTP id c89mr29975524pfe.37.1525511199876; Sat, 05 May 2018 02:06:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525511199; cv=none; d=google.com; s=arc-20160816; b=s2vp6lltnIpWaYJ+AmAvlBBq+ezAvGlCoO3OtdCPqhUWET6scQdTvqWo2ZbEBzb6Ku WCJlDcEs0s/KMSKocDCb0i4a4rsoV3IGaB43tjCjhPsr3zvGf6QO/YaPkguEZAitgEuh yU3Yeckoc2s7FGAJ4H+UUASQjbe/SSewZ7UVKLNTRwH4g+4fIBNIyHB5dkTg264HbH3K xHfGBMBWWhIpJaEVSajhK1N/IGq7mg2lMz0atgr1AUvRH529GEn38BqUGKKkDbYTNXrA DxjOJ+7qzqi8/AjawJrQKSojNI/1qc3X96SfriyMlB//EVWNlJs/8nkmpQJJaAmFb2l/ PayA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=cuba3bIIR71GYMewlz5ZKObOEICtVNv4zbVEJjYHdsE=; b=tROE2Ass7uk9OEoFFo3dz9IBvT/jlRAuhdaZGf7uRzW0HxqsohpxznG15CyBP2JrR2 LXHj2YD89P3wt8gcbrhEIJ3TJuBpcHioFsC+lo/Keq2yfe3/pDKO2n9WQXfBVn2gNmQ5 s7k09Nn1YmDFOypTWSAOyQI0kOGrfh+4NzNoKfSfbW/LMjFa/SdR3sCcLyhGV/r3T5rp syMFnuTqKTbTzbmm31ITvdfnlHnQ7qd2gu2lt6bHEbC1eAh/XzKYe8ekKvFXfNBmi5vE fu4akYNi5Teyl29bo9qTi+kyP7a0vIS16GtphO+hgw9+uyrDDN52NS1rwh1Ykkyuz3tt UQSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Et3zCkAG; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d124si2454359pfc.176.2018.05.05.02.06.25; Sat, 05 May 2018 02:06:39 -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=pass header.i=@google.com header.s=20161025 header.b=Et3zCkAG; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751235AbeEEJGO (ORCPT + 99 others); Sat, 5 May 2018 05:06:14 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:37322 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750764AbeEEJGN (ORCPT ); Sat, 5 May 2018 05:06:13 -0400 Received: by mail-pf0-f196.google.com with SMTP id e9so15223593pfi.4 for ; Sat, 05 May 2018 02:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cuba3bIIR71GYMewlz5ZKObOEICtVNv4zbVEJjYHdsE=; b=Et3zCkAG0Gdi/kVZTX3ilBJNLhpGLzJwExJcIObsOFvDrJMJF3zclqEI8lYgVvFqT2 Ccl8V8f/SjiStVNA8RElksGFXu4e/hNx/ugBXDOvIAxkMLUBZ2E28gT/r/9l+nfLaKZd j6hL4TXp6m/5vPPVXiBxyMAJc5ytCoRp4hcBkhQUmbI1W3nTt/w12tEB9GSwh2i3abt0 PgGawEem7hzYZ8aG4wmyt9htRLttFGr9SBoEUluSzKquBznHIt0wqPjLztw3K4ZNHP7q DwsMTg99z/awHJasRAB9M/P8ooGDPRxjH6tRbXuS1EAaIsJke07OBjyhMgzzzSRCoZx2 K4GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cuba3bIIR71GYMewlz5ZKObOEICtVNv4zbVEJjYHdsE=; b=VcmAxH/UCsaQC2xps+5+S9A5qy09Vk4LbSsF1WwAN+CL3yzlRmCtlsxEGEW/TseJ8N hv29bMrLWEOt/OkX6va5mjgEzdUqaJ6KesDEfjnfFUH8zvFViUOYPXn+GJDi+CaPh5A/ LohA68dbH2wlqH6UOZ7j7UAwiID25ATOslX3M6BpQx598a9tMEpCKE5ZqvjBRRvInuGR K6UWZxPZad6TsSuysxIVQAMlZ8mCFRg1du4rRrIAqSr00RIOSp2OfyO5xUGcG51N/8cP dWuysksEe9tipZXjqN05SkXbFUR0MeZIY2Gp1he1zHPSh1LzmZLWkbKOdAbdeXReePox e0Vg== X-Gm-Message-State: ALQs6tBmThnwZg9n4vQSiYJBs7RoMrormhlvIwhRXZ8Gxd0MRJLUxcW/ KPcMXV/S768+f+3HrPnDi+nbMsHn9pljKKRC78ZAVQ== X-Received: by 10.98.211.82 with SMTP id q79mr30156638pfg.45.1525511172508; Sat, 05 May 2018 02:06:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.149.24 with HTTP; Sat, 5 May 2018 02:05:51 -0700 (PDT) In-Reply-To: <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> <20180505084721.GA32344@noisy.programming.kicks-ass.net> From: Dmitry Vyukov Date: Sat, 5 May 2018 11:05:51 +0200 Message-ID: Subject: Re: [PATCH] locking/atomics: Clean up the atomic.h maze of #defines To: Peter Zijlstra Cc: Ingo Molnar , Mark Rutland , Linux ARM , LKML , Andrey Ryabinin , Boqun Feng , Catalin Marinas , Will Deacon Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 5, 2018 at 10:47 AM, Peter Zijlstra wrote: > 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. That was asked by Ingo: https://groups.google.com/d/msg/kasan-dev/3sNHjjb4GCI/Xz1uVWaaAAAJ I think in the end all of current options suck in one way or another, so we are just going in circles. We either need something different (e.g. codegen), or settle on one option for doing it.