Steve Underwood <steveu@xxxxxxxxxxx> wrote: >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. 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. -Andy 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
