On 12/30/2013 07:54 PM, Andy Green wrote:
Gordan Bobic <gordan@xxxxxxxxxx> wrote:
On 12/30/2013 09:58 AM, Andy Green wrote:
Gordan Bobic <gordan@xxxxxxxxxx> 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
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 I
can't think of anything which will keep the number of misalignment
issues down.
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. Things like autoconf tests make it easy
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 accepting
them (if they are even accepted).
Gordan
Regards,
Steve
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
