lkml.org 
[lkml]   [2019]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8
Date
From:  Vineet Gupta
> Sent: 12 February 2019 17:17
>
> On 2/8/19 2:55 AM, Alexey Brodkin wrote:
> > By default ARCH_SLAB_MINALIGN is defined in "include/linux/slab.h" as
> > "__alignof__(unsigned long long)" which looks fine but not for ARC.
>
> Just for the record, the issue happens because a LLOCKD (exclusive 64-bit load)
> was trying to use a 32-bit aligned effective address (for atomic64_t), not allowed
> by ISA (LLOCKD can only take 64-bit aligned address, even when the CPU has
> unaligned access enabled).
>
> This in turn was happening because this word is embedded in some other struct and
> happens to be 4 byte aligned
>
>
> > ARC tools ABI sets align of "long long" the same as for "long" = 4
> > instead of 8 one may think of.

Right, but __alignof__() doesn't have to return the alignment that would
be used for a data item of the specified type.
(Read the gcc 'bug' info for gory details.)

On i386 __alignof__(long long) is 8, but structure members of type 'long long'
are 4 byte aligned and the alignment of a structure with a 'long long' member
is only 4.
(Although the microsoft compiler returns 4.)

> Right, this was indeed unexpected and not like most other arches. ARCv2 ISA allows
> regular 64-bit loads/stores (LDD/STD) to take 32-bit aligned addresses. Thus ABI
> relaxing the alignment for 64-bit data potentially causes more packing and less
> space waste. But on the flip side we need to waste space at arbitrary places liek
> this.
>
> So this is all good and theory, but I'm not 100% sure how slab alignment helps
> here (and is future proof). So the outer struct with embedded atomic64_t was
> allocated via slab and your patch ensures that outer struct is 64-bit aligned ?

Presumable 'atomic64_t' has an alignment attribute to force 8 byte alignment.

> But how does that guarantee that all embedded atomic64_t in there will be 64-bit
> aligned (in future say) in the light of ARC ABI and the gcc bug/feature which
> Peter alluded to
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54188
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10360
>
> > Thus slab allocator may easily allocate a buffer which is 32-bit aligned.
> > And most of the time it's OK until we start dealing with 64-bit atomics
> > with special LLOCKD/SCONDD instructions which (as opposed to their 32-bit
> > counterparts LLOCK/SCOND) operate with full 64-bit words but those words
> > must be 64-bit aligned.
>
> Some of this text needed to go above to give more context.

I suspect the slab allocator should be returning 8 byte aligned addresses
on all systems....

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
\
 
 \ /
  Last update: 2019-02-12 18:30    [W:0.046 / U:0.048 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site