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

[Gordan Bobic]

On 12/27/2013 09:48 AM, Steve Underwood wrote:
> On 12/27/2013 05:23 PM, Gordan Bobic wrote:
>> On 12/27/2013 08:32 AM, Richard W.M. Jones wrote:
>>> On Thu, Dec 26, 2013 at 07:49:58PM +0000, Gordan Bobic wrote:
>>>> On 12/26/2013 02:20 PM, Derek Atkins wrote:
>>>>> Gordan Bobic <gordan at bobich.net> writes:
>>>>>
>>>>>> (e.g. (but not limited to) a large number of packages make little or
>>>>>> no effort to ensure memory accesses are aligned - including the likes
>>>>>> of e2fsprogs, and transparent alignment fixup in hardware is only
>>>>>> available on armv7 and later).
>>>>>
>>>>> I'm surprised that Ted isn't willing to fix issues in e2fsprogs.
>>>>>
>>>>> If you can point me to the upstream bug reports I can ping him to see
>>>>> what's up?
>>>>
>>>> Take a look here:
>>>> http://comments.gmane.org/gmane.comp.file-systems.ext4/33324
>>>>
>>>> As has been mentioned before, there is a whole shedload of packages
>>>> that have similar issues - I have seen literally thousands of
>>>> alignment faults get reported (I have the alignment set to fix+warn
>>>> on my armv5tel builders) in various packages during build and test
>>>> stages. Once upon a time I planned to collate the data and get the
>>>> issue reported to all upstream maintainers, but that is a mammoth
>>>> task just to report, let alone fix, and I have very little faith
>>>> there is enough will among the developers to fix all the affected
>>>> packages and ensure they write code that isn't affected by this
>>>> problem going forward.
>>>
>>> I disagree that it is even a problem; except in a very small number of
>>> cases where it causes a measurable slowdown.
>>
>> It's a more philosophical issue - since alignment issues arguably
>> arise from poor programming practice in the first place, should there
>> be pressure to not produce code that suffers from such issues?
 >
> If you make an x86 machine work through alignment issues in software,
> rather than let the hardware sort it out, you will pay a speed penalty.

How is transparent alignment fixup going to give you back the 
performance you lose from accesses straddling cache lines?

> In a lot of protocol code misalignment is forced upon you by the
> protocol, and sorting it out in software can lead to a *considerable*
> speed penalty.

Fair, I can see this being one case where alignment auto-fixup is 
beneficial, but how many commonly used protocols are there where this is 
actually a problem? Has anyone ever assessed this comprehensively? Is 
there a list somewhere?

Gordan