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

[Andy Green]

Gordan Bobic <gordan at bobich.net> wrote:
>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.

It's already tractable, you're choosing not to engage with solving it upstream.

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

Nonsense... a few years ago I made my own cross distro for an ARM9 device without hardware fixup, entirely from source tarballs, and there were almost no alignment issues in the major projects.

I guess they will tend to start to increase since more people are using newer ARM SoC which all have hardware fixup - but you are the backpressure against that by providing patches for the real problems you found... at least if you care about it, you should be.

-Andy

>investigate 
>all of them, write patches, and chase the upstream through to accepting
>
>them (if they are even accepted).
>
>Gordan