[fedora-arm] Fedora 20 for Raspberry Pi????

Gordan Bobic gordan at bobich.net
Mon Dec 30 11:45:59 UTC 2013

On 12/30/2013 09:58 AM, Andy Green wrote:
> Gordan Bobic <gordan at bobich.net> wrote:
>> On 12/27/2013 04:02 PM, Richard W.M. Jones wrote:
>>> On Fri, Dec 27, 2013 at 09:53:54AM +0000, Gordan Bobic wrote:
>>>> How is transparent alignment fixup going to give you back the
>>>> performance you lose from accesses straddling cache lines?
>>> You can have structs straddling cache lines and causing performance
>>> problems without alignment issues, or structs being packed too close
>>> together causing false sharing again w/o alignment being involved.
>>> If alignment problems cause performance issues, then we should deal
>>> with those performance problems.  If they don't, we shouldn't worry
>>> about them.
>>> Rich.
>>> ObHack: I once worked with an architecture [68k-based VME hardware]
>>> that not only faulted on unaligned access, but also on accesses of
>> the
>>> wrong *size* (eg. using a short-sized read instruction instead of a
>>> word-sized read instruction).  Dealing with that nonsense involved a
>>> lot of compiler-specific massaging of code and some inline assembly
>> ...
>> I'm very glad you mentioned compilers - this is in fact easily fixable
>> at compiler level. Intel's ICC has an option to make all arrays and
> No, if your code takes the approach to cast the struct pointer into a byte stream, the struct pointer itself can be unaligned.

It won't fix all cases, but it will fix a large chunk of them - perhaps 
enough of them to make fixing the remainder a tractable problem.

> Your compiler can do nothing about that, you have to touch the members using bytewise accessors to be compatible with SoCs that don't fix up unaligned access properly.
>> structs always aligned to a boundary (up to 16 byte, IIRC). If GCC were
>> to implement such a feature the problem could be made to go away
>> without
>> actually addressing the underlying cause of the problem. It might be a
>> bodge, but since complete fix of the underlying problem isn't going to
>> happen anyway, a good bodge would be a lot better than doing nothing.
> What's wrong with you sending patches to the upstream?

Nothing apart from the amount of man-months it would take to investigate 
all of them, write patches, and chase the upstream through to accepting 
them (if they are even accepted).


More information about the arm mailing list