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 >investigate >all of them, write patches, and chase the upstream through to accepting > >them (if they are even accepted). > >Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
