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

[Steve Underwood]

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. 
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.
>> Is there a way to find
>> out if a program is doing an excessive number of alignment fixups?
>
> Mostly - run with fix+warn
> # echo 3 > /proc/cpu/alignment
> and keep an eye on syslog (or get logwatch to do so for you).
>
> If you have a relatively simple setup (basic LAMP server and little 
> else), hardly anything gets logged. If you have a koji/mock farm, the 
> syslog is flooded with the warnings. I haven't actually measured this, 
> but my impression is that a non-trivial fraction of the alignment 
> warnings actually occur in the test suites for various packages that 
> support them.
>
>> Basically this is an architectural problem in ARM, and not something
>> developers should go through hoops to fix except in the tiny number of
>> cases where it causes an actual, measurable problem.
>
> There are always performance drawbacks to not paying attention to 
> alignment, since unaligned access also end up straddling cache lines, 
> which also comes with a performance hit, even when there is 
> transparent alignment auto-fixup in hardware.
>
> IIRC, SPARC and Itanium also have, or at least had issues with 
> unaligned accesses. I don't know if they introduced a transparent 
> fixup in hardware since.
>
> It's also not a case of jumping through hoops, it's a matter of not 
> using poor practices such as allocating arrays of char for buffers and 
> then casting them into structs.
>
> Gordan
Regards,
Steve