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

[Gordan Bobic]

On 12/30/2013 11:54 AM, Andy Green wrote:
>
>
> 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.

I'll enumerate the instances of this next time I'm doing a RedSleeve 
rebuild (might start this week when I resurrect my Koji farm of armv5tel 
devices). Last time I checked the number of instances logged was in the 
hundreds - sufficiently high that I just gave up.

>>> 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 did the same 18 months ago, and my experience was distinctly 
different. Thankfully, with the kernel-level alignment fixup at least 
building the distro was tractable.

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

A fair point well made, but I don't think we entirely agree on the scale 
of the problem.

Gordan