Catalin Marinas [off-list ref] writes:

2011/5/24 M?ns Rullg?rd [off-list ref]:

quoted

Catalin Marinas [off-list ref] writes:

quoted

On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:

quoted

On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:

quoted

Newer versions of gcc generate unaligned accesses by default, causing
kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
-mno-unaligned-access option to gcc.

This description doesn't make sense. ?If we have alignment traps enabled,
then we _expect_ to fix up unaligned loads and stores.

Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.

So what's the _actual_ problem that this is trying to address? ?What's
the panic/oops look like? ?And that information should be in the commit
description _anyway_.

Does the patch below look better?

We cannot move alignment_init() earlier as we don't know how early the
compiler would generate unaligned accesses. An alternative is some
#ifdef's in head.S. Please let me know which variant you prefer.

ifdefs may be ugly, but I don't see a better solution here. ?Crippling
the entire build to make a couple of lines slightly more aesthetically
pleasing doesn't seem right to me.

BTW, are we sure that the code generated with unaligned accesses is
better? AFAIK, while processors support unaligned accesses, they may
not always be optimal.

On Cortex-A8 unaligned loads not crossing a 128-bit boundary have no
penalty.  Crossing a 128-bit boundary stalls for 9 cycles (measured, 8
according to TRM).  On Cortex-A9, unaligned loads crossing a 64-bit
boundary delay 7 cycles (measured), other misalignments have no penalty.
On average these timings are faster than doing 4 byte loads and oring
them together, which uses 6 cycles on A9, 9 cycles on A8.

It may of course be the case that unaligned accesses are rare enough
that this isn't worth worrying about at all.

-- 
M?ns Rullg?rd
mans at mansr.com