From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
catalin.marinas@arm.com, benh@kernel.crashing.org,
tony.luck@intel.com, takata@linux-m32r.org, lethal@linux-sh.org,
tglx@linutronix.de, davem@davemloft.net, deller@gmx.de
Subject: Re: [RFC PATCH 00/16] Remove unused arch_*_relax operations from spinlocks
Date: Fri, 28 Jun 2013 09:31:03 +0200 [thread overview]
Message-ID: <20130628093103.216d4d6e@mschwide> (raw)
In-Reply-To: <20130624115825.GJ23779@mudshark.cambridge.arm.com>
On Mon, 24 Jun 2013 12:58:25 +0100
Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jun 21, 2013 at 06:17:21PM +0100, Will Deacon wrote:
> > This is an RFC cleanup series removing the unused
> > arch_{spin,read,write}_relax macros from (nearly) all architectures that
> > define them. The macros have no users in core code and are typically
> > synonymous with cpu_relax(), the notable exceptions being PowerPC (where
> > the thing is still unused) and S390.
>
> So the `no users in core code' part isn't quite true...
>
> With GENERIC_LOCKBREAK (arm64, ia64, m32r, parisc, powerpc, s390, sh and
> sparc), we can actually spit out arch_*_relax calls in kernel/spinlock.c
> using some macro concatenation that defeated my grep-fu.
>
> This only makes a difference on powerpc and s390, so we could either:
>
> (1) conditionally define the relax macros as cpu_relax in spinlock.c (so
> the two guys above can have their special versions)
>
> (2) Replace the calls with calls to cpu_relax() (although powerpc seems to
> want to know who owns the lock in order to relax)
>
> (3) Leave the current code alone for architectures that may select
> GENERIC_LOCKBREAK
>
> Any other ideas/preferences?
Yeah, we never came around to implement arch_read/write_relax. We can remove
the two defines for s390, if we want to add some logic there we can just re-add
an appropriate definition. As powerpc is optimizing their read/write locks
with GENERIC_LOCKBREAK=y we should leave the ability to override the relax
function as it is, no?
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2013-06-28 7:31 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-21 17:17 [RFC PATCH 00/16] Remove unused arch_*_relax operations from spinlocks Will Deacon
2013-06-21 17:17 ` [RFC PATCH 01/16] alpha: locks: remove unused arch_*_relax operations Will Deacon
2013-06-21 17:17 ` [RFC PATCH 02/16] arc: " Will Deacon
2013-06-24 4:12 ` Vineet Gupta
2013-06-24 8:58 ` Will Deacon
2013-06-21 17:17 ` [RFC PATCH 03/16] ARM: " Will Deacon
2013-06-21 17:17 ` [RFC PATCH 04/16] arm64: " Will Deacon
2013-06-21 17:17 ` [RFC PATCH 05/16] blackfin: " Will Deacon
2013-06-21 17:17 ` [RFC PATCH 06/16] cris: " Will Deacon
2013-06-24 6:41 ` Jesper Nilsson
2013-06-21 17:17 ` [RFC PATCH 07/16] ia64: " Will Deacon
2013-06-21 17:17 ` [RFC PATCH 08/16] m32r: " Will Deacon
2013-06-21 17:17 ` [RFC PATCH 09/16] metag: " Will Deacon
2013-06-24 9:07 ` James Hogan
2013-06-21 17:17 ` [RFC PATCH 10/16] mips: " Will Deacon
2013-06-21 17:48 ` David Daney
2013-06-21 17:17 ` [RFC PATCH 11/16] hppa: " Will Deacon
2013-06-21 18:32 ` Fwd: " Helge Deller
2013-06-24 8:55 ` Will Deacon
2013-06-24 11:37 ` Will Deacon
2013-06-21 17:17 ` [RFC PATCH 12/16] powerpc: " Will Deacon
2013-06-21 22:16 ` Benjamin Herrenschmidt
2013-06-21 17:17 ` [RFC PATCH 13/16] s390: " Will Deacon
2013-06-21 17:17 ` [RFC PATCH 14/16] sh: " Will Deacon
2013-06-21 17:17 ` [RFC PATCH 15/16] sparc: " Will Deacon
2013-06-21 19:18 ` David Miller
2013-06-21 17:17 ` [RFC PATCH 16/16] x86: " Will Deacon
2013-06-21 20:48 ` Thomas Gleixner
2013-06-24 11:58 ` [RFC PATCH 00/16] Remove unused arch_*_relax operations from spinlocks Will Deacon
2013-06-28 7:31 ` Martin Schwidefsky [this message]
2013-07-01 8:53 ` Will Deacon
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=20130628093103.216d4d6e@mschwide \
--to=schwidefsky@de.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=takata@linux-m32r.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=will.deacon@arm.com \
/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.