Re: [PATCH] FLAT: allow arches to declare a larger alignment than the slab

[Paul Mundt]

On Tue, May 25, 2010 at 07:17:16PM -0400, Mike Frysinger wrote:
> FLAT is using ARCH_SLAB_MINALIGN to align the stack and align the data
> section.  as such, Blackfin needs 4 byte alignment here.  the previous
> FLAT behavior was "use arch slab sizes if defined, otherwise use
> sizeof(void*)".  this worked fine for us size sizeof(void*) == 4.
> 
> now with ARCH_SLAB_MINALIGN being in global space, this defaults to 0
> for us and the manual stack & data alignment no longer work.
> 
> i'm a schlub when it comes to these allocators, so i know as much as
> the documentation states.  slab_def.h says:
>  * Enforce a minimum alignment for all caches.
>  * Intended for archs that get misalignment faults even for BYTES_PER_WORD
>  * aligned buffers.
> 
> this comment does not seem to apply to Blackfin as BYTES_PER_WORD is 4
> and we can work with anything aligned to 4 bytes.
> 
The comment here is a bit misleading, it's true that SLAB will happily
align to BYTES_PER_WORD as a default if nothing else is specified, but
it's also true that a growing number of structures contain 64-bit values
that need to be accessed on 64-bit boundaries on 32-bit platforms. If
this doesn't apply to blackfin then simply sticking with the default is
fine. SLAB/SLOB will align to 4 bytes while SLUB will presently align to
8.

> to be sure, we dont need 0x20 alignment in general.  i just figured
> kill two birds with one patch here.  and Blackfin is already setting
> ARCH_KMALLOC_MINALIGN to cacheline size, but that wouldnt make any
> difference in these issues.

I have no objections to adding a new alignment value for binfmt_flat, but
given the confusion that exists around things like ARCH_SLAB_MINALIGN and
ARCH_KMALLOC_MINALIGN already today it should be quite obvious what
exactly the new value is for and what case it is specifically addressing.
My guess is that the issues you are seeing with the gcc testsuite will
also pop up on other nommu platforms, so it may be something we want to
just deal with generically. At least I suspect you guys are running the
gcc testsuite a lot more frequently than the rest of us!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/