From: Peter Zijlstra <peterz@infradead.org>
To: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Vineet Gupta <vineet.gupta1@synopsys.com>,
David Laight <David.Laight@ACULAB.COM>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
Arnd Bergmann <arnd.bergmann@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8
Date: Thu, 14 Feb 2019 11:28:15 +0100 [thread overview]
Message-ID: <20190214102815.GF32494@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <4881796E12491D4BB15146FE0209CE64681DB01F@DE02WEMBXB.internal.synopsys.com>
On Thu, Feb 14, 2019 at 08:50:43AM +0000, Alexey Brodkin wrote:
> But that's pretty much the same for other 32-bit arches that have 64-bit atomics
> like ARM etc. From what I may see from ARM's documentation for LDREXD/SRREXD they
> require double-word alignment of data as well.
>
> That said if for some reason atomic64_t variable is unaligned execution on
> any (or at least most) 32-bit architectures will lead to run-time failure,
> i.e. we'll know about it and this will be fixed.
On x86_32 we have cmpxchg8b that 'likes' 8b alignment, our atomic64_32
implementation has the explicit alignment in, however there
__alignof__(unsigned long long) is actually 8, so it all works.
Even though the hardware (obviously) never really requires alignment,
even for atomic ops (although that's coming, yay!).
next prev parent reply other threads:[~2019-02-14 10:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 10:55 [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8 Alexey Brodkin
2019-02-12 17:17 ` Vineet Gupta
2019-02-12 17:30 ` David Laight
2019-02-12 17:45 ` Vineet Gupta
2019-02-13 12:56 ` Peter Zijlstra
2019-02-13 14:13 ` David Laight
2019-02-13 23:23 ` Vineet Gupta
2019-02-14 8:50 ` Alexey Brodkin
2019-02-14 10:28 ` Peter Zijlstra [this message]
2019-02-15 1:34 ` Vineet Gupta
2019-02-18 8:53 ` Alexey Brodkin
2019-02-19 23:30 ` Vineet Gupta
2019-02-14 10:31 ` Peter Zijlstra
2019-02-14 10:44 ` Alexey Brodkin
2019-02-14 11:08 ` Peter Zijlstra
2019-02-14 12:05 ` Alexey Brodkin
2019-02-14 12:24 ` Peter Zijlstra
2019-02-14 14:14 ` David Laight
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=20190214102815.GF32494@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=David.Laight@ACULAB.COM \
--cc=alexey.brodkin@synopsys.com \
--cc=arnd.bergmann@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=stable@vger.kernel.org \
--cc=vineet.gupta1@synopsys.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).