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

[Gordan Bobic]

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).

Gordan