All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	boqun.feng@gmail.com, Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCHv2 11/11] arm64: use instrumented atomics
Date: Wed, 4 Jul 2018 18:41:34 +0100	[thread overview]
Message-ID: <20180704174133.GD9668@arm.com> (raw)
In-Reply-To: <20180704163721.lxuynjd4dflcyucm@lakrids.cambridge.arm.com>

On Wed, Jul 04, 2018 at 05:37:23PM +0100, Mark Rutland wrote:
> On Wed, Jul 04, 2018 at 04:24:22PM +0100, Will Deacon wrote:
> > This is mostly straightforward, but the cmpxchg/cmpxchg_double cases grow
> > an 'arch' prefix which suggests that they're part of the API with the core
> > atomics and also makes them horribly ugly.
> 
> I agree this isn't nice.
> 
> > This just looks to be an artifact of __LL_SC_CALL pasting that in. Can
> > you drop that auto pasting of 'arch', and instead change the
> > non-cmpxchg-case callers of the macro to include the arch prefix
> > instead, please?
> 
> That leads to having an arch___llsc_ prefix in some cases, which is
> equally hideous.

Yuck, how does that come about?

> How about I remove the prefix mangling entirely, and always give
> functions an __llsc_ or __lse_ prefix. Then, unify the two in our
> atomic.h with:
> 
> #ifdef CONFIG_ARM64_LSE
> #define ATOMIC_PFX	__lse_
> #else
> #define ATOMIC_PFX	__ll_sc_
> #endif
> 
> #define arch_atomic_foo		ATOMIC_PFX##atomic_foo
> #define arch_atomic_bar		ATOMIC_PFX##atomic_bar
> 
> ... which clearly delineates the implementation from core API.
> 
> Does that sound ok to you?

Why do we need two prefixes? The only reason we throw out __ll_sc_ at the
moment is so the out-of-line atomics have a different name from the inlined
ones. What I'd like is:

	atomic_foo
	-> arch_atomic_foo
	   -> optionally calls __ll_sc_arch_atomic_foo

which I think is very similar to what we already do (i.e. the inlined macro
is always called arch_atomic_foo, regardless of lse or ll/sc).

Will

  reply	other threads:[~2018-07-04 17:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-25 10:59 [PATCHv2 00/11] atomics: generate atomic headers / instrument arm64 Mark Rutland
2018-06-25 10:59 ` [PATCHv2 01/11] atomic/tty: Fix up atomic abuse in ldsem Mark Rutland
2018-06-26 18:53   ` Andy Shevchenko
2018-06-26 19:30     ` Peter Zijlstra
2018-06-27 17:33       ` Andy Shevchenko
2018-06-25 10:59 ` [PATCHv2 02/11] atomics/x86: reduce arch_cmpxchg64*() instrumentation Mark Rutland
2018-06-25 10:59 ` [PATCHv2 03/11] atomics: simplify cmpxchg() instrumentation Mark Rutland
2018-06-25 11:38   ` Andrea Parri
2018-06-25 11:47     ` Dmitry Vyukov
2018-06-25 11:48     ` Mark Rutland
2018-06-25 10:59 ` [PATCHv2 04/11] atomics/treewide: instrument xchg() Mark Rutland
2018-06-25 10:59 ` [PATCHv2 05/11] atomics: instrument cmpxchg_double*() Mark Rutland
2018-06-25 10:59 ` [PATCHv2 06/11] atomics/treewide: rework ordering barriers Mark Rutland
2018-06-25 15:44   ` Mark Rutland
2018-07-04 15:06   ` Will Deacon
2018-07-04 15:56     ` Mark Rutland
2018-07-04 17:50       ` Will Deacon
2018-07-05 10:12         ` Mark Rutland
2018-07-05 16:25           ` Will Deacon
2018-06-25 10:59 ` [PATCHv2 07/11] atomics: add common header generation files Mark Rutland
2018-06-28 10:58   ` Mark Rutland
2018-06-28 11:46     ` Peter Zijlstra
2018-06-25 10:59 ` [PATCHv2 08/11] atomics: switch to generated fallbacks Mark Rutland
2018-07-04 15:28   ` Will Deacon
2018-07-04 16:01     ` Mark Rutland
2018-07-04 17:44       ` Will Deacon
2018-07-05 11:52         ` Mark Rutland
2018-06-25 10:59 ` [PATCHv2 09/11] atomics: switch to generated atomic-long Mark Rutland
2018-06-25 10:59 ` [PATCHv2 10/11] atomics: switch to generated instrumentation Mark Rutland
2018-06-25 10:59 ` [PATCHv2 11/11] arm64: use instrumented atomics Mark Rutland
2018-07-04 15:24   ` Will Deacon
2018-07-04 16:37     ` Mark Rutland
2018-07-04 17:41       ` Will Deacon [this message]
2018-07-05  9:58         ` Mark Rutland
2018-06-25 15:22 ` [PATCHv2 00/11] atomics: generate atomic headers / instrument arm64 Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180704174133.GD9668@arm.com \
    --to=will.deacon@arm.com \
    --cc=boqun.feng@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.