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

Andy Green andy at warmcat.com
Mon Dec 30 14:27:38 UTC 2013

Steve Underwood <steveu at coppice.org> wrote:
>On 12/30/2013 07:54 PM, 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
>>>>>> problems without alignment issues, or structs being packed too
>>> close
>>>>>> together causing false sharing again w/o alignment being
>>>>>> If alignment problems cause performance issues, then we should
>>>>>> with those performance problems.  If they don't, we shouldn't
>>>>>> about them.
>>>>>> Rich.
>>>>>> ObHack: I once worked with an architecture [68k-based VME
>>>>>> that not only faulted on unaligned access, but also on accesses
>>>>> the
>>>>>> wrong *size* (eg. using a short-sized read instruction instead of
>>>>>> word-sized read instruction).  Dealing with that nonsense
>>> a
>>>>>> lot of compiler-specific massaging of code and some inline
>>>>> ...
>>>>> 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
>>>> No, if your code takes the approach to cast the struct pointer into
>>> byte stream, the struct pointer itself can be unaligned.
>>> It won't fix all cases, but it will fix a large chunk of them -
>>> enough of them to make fixing the remainder a tractable problem.
>> It's already tractable, you're choosing not to engage with solving it
>>>> Your compiler can do nothing about that, you have to touch the
>>> members using bytewise accessors to be compatible with SoCs that
>>> 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
>>> a
>>>>> bodge, but since complete fix of the underlying problem isn't
>>> 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
>In recent years i think most instances of misalignment in packages has 
>been picked up by openwrt/ddwrt/tomato/etc users, as most routers have 
>MIPS processors, and most of these can't correct misalignment. So far 
>the routers seem to be continuing with MIPS cores. If they move to ARM
>can't think of anything which will keep the number of misalignment 
>issues down.

Yes I think those guys and older arm arch guys have been responsible for keeping everything almost clean until now.

>You can't blame programmers for leaving alignment issues in their code.
>I try to keep my code alignment safe, but without a test platform where
>alignment matters I just can't tell if I have missed something. You can
>blame programmers if they won't make a real effort to flush out those 
>problems when they are reported.

Yeah I think until you realize why and how it's a problem (in other words, you got bitten) most programmers wouldn't particularly think to defend against it because the code is c-legal and works on x86.


 Things like autoconf tests make it
>to use special handling of misalignment where it is needed, and let the
>hardware handle it where it can. It is hard to ensure you have caught 
>every instance where optional processing needs to occur.
>>> investigate
>>> all of them, write patches, and chase the upstream through to
>>> them (if they are even accepted).
>>> Gordan
>arm mailing list
>arm at lists.fedoraproject.org

More information about the arm mailing list