On 2/18/19 12:53 AM, Alexey Brodkin wrote:
> So are you OK with this patch or something should be done before applying?
Or your original patch was
+#ifdef CONFIG_ARC_HAS_LL64
+#define ARCH_SLAB_MINALIGN 8
+#endif
I don't think this issue is related to LL64 at all. A long long on ARC could
er.kernel.org; Mark Rutland
>
> Subject: Re: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8
>
> On 2/14/19 12:50 AM, Alexey Brodkin wrote:
>
> >>>>> I suspect the slab allocator should be returning 8 byte aligned
> >>>>> addresses
> >&g
On 2/14/19 12:50 AM, Alexey Brodkin wrote:
> I suspect the slab allocator should be returning 8 byte aligned addresses
> on all systems
why ? As I understand it is still not fool proof against the expected
alignment of
inner members. There ought to be a better way
From: Peter Zijlstra
> Sent: 14 February 2019 11:08
> On Thu, Feb 14, 2019 at 10:44:49AM +, Alexey Brodkin wrote:
> > > On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
> > > > On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> > > > >
> > > > > Personally I think u64 and company should
On Thu, Feb 14, 2019 at 12:05:47PM +, Alexey Brodkin wrote:
> > > > So what happens if the data is then split across two cachelines; will a
> > > > STD vs LDD still be single-copy-atomic? I don't _think_ we rely on that
> > > > for > sizeof(unsigned long), with the obvious exception of
; ; Arnd Bergmann
> ; linux-snps-...@lists.infradead.org
> Subject: Re: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8
>
> On Thu, Feb 14, 2019 at 10:44:49AM +, Alexey Brodkin wrote:
> > > On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
On Thu, Feb 14, 2019 at 10:44:49AM +, Alexey Brodkin wrote:
> > On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
> > > On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> > > >
> > > > Personally I think u64 and company should already force natural
> > > > alignment; but alas.
> > >
> > >
er.kernel.org; Mark Rutland
> Subject: Re: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8
>
> On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
> > On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> > >
> > > Personally I think u64 and co
On Wed, Feb 13, 2019 at 03:23:36PM -0800, Vineet Gupta wrote:
> On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> >
> > Personally I think u64 and company should already force natural
> > alignment; but alas.
>
> But there is an ISA/ABI angle here too. e.g. On 32-bit ARC, LDD (load double)
> is
>
On Thu, Feb 14, 2019 at 08:50:43AM +, 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
> sta...@vger.kernel.org; Mark Rutland
> Subject: Re: [PATCH] ARC: Explicitly set ARCH_SLAB_MINALIGN = 8
>
> On 2/13/19 4:56 AM, Peter Zijlstra wrote:
> >
> > Personally I think u64 and company should already force natural
> > alignment; but alas.
>
> But there
On 2/13/19 4:56 AM, Peter Zijlstra wrote:
>
> Personally I think u64 and company should already force natural
> alignment; but alas.
But there is an ISA/ABI angle here too. e.g. On 32-bit ARC, LDD (load double) is
allowed to take a 32-bit aligned address to load a register pair. Thus all u64
need
From: Peter Zijlstra
> Sent: 13 February 2019 12:57
...
...
> In the past I've proposed a GCC plugin / checker that would verify the
> alignment requirements against the various allocators.
>
> For instance:
>
> struct foo {
> spinlock_t a;
> int b;
> } __cacheline_aligned;
>
>
On Tue, Feb 12, 2019 at 09:45:53AM -0800, Vineet Gupta wrote:
> +CC some folks interested in alignment stuff in the past.
>
> On 2/12/19 9:30 AM, David Laight wrote:
> > From: Vineet Gupta
> >> Sent: 12 February 2019 17:17
> >>
> >> On 2/8/19 2:55 AM, Alexey Brodkin wrote:
> >>> By default
+CC some folks interested in alignment stuff in the past.
On 2/12/19 9:30 AM, David Laight wrote:
> 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
>>>
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
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
By default ARCH_SLAB_MINALIGN is defined in "include/linux/slab.h" as
"__alignof__(unsigned long long)" which looks fine but not for ARC.
ARC tools ABI sets align of "long long" the same as for "long" = 4
instead of 8 one may think of.
Thus slab allocator may easily allocate a buffer which is
18 matches
Mail list logo
