Dear Wolfgang,
On 9.3.2018 12:26, Wolfgang Denk wrote:
Dear Michal,
In message f144e491-5ce5-2ad0-70a8-d36397752863@xilinx.com you wrote:
Can you please add some comments what the consequences of this change are? I guess there are advantages, but I also guess these come at a price?
That's something what I am expecting from this discussion if there are any corner cases which we are not aware of.
We found this setting based on randomized testing where simply non aligned access for memory read was causing exception.
Hm... One possible position one can take is that unaligned accesses are likely an indication for incorrect or sloppy programming. usually we design data structures, buffers etc. such that no unaligned accesses take place. Most code is explicitly written in such a way that it also runs on architectures where unaligned access simply don't work.
I feel that providing such an option just opens the door for lousy programmers who don't think throroughly about the code they write.
Yes, in some cases this may be conveniendt. But there are also cases where the problem is just papered over, and hits all the harder later like when you also enable caching.
Thi is why I'm asking for the advantages. If it's just is that broken code starts working, then I'd rather see a clear error message that forces the code to be fixed.
We are not seeing any issue from u-boot code itself and I can believe that structures and accesses are aligned properly.
The initial reason was that u-boot allows you to run for example command md 1 and it ends up in panic. Which is something what should be possible to run or code should check that architecture has alignment restriction.
Definitely panic is not proper reaction on command like this. It means we have two options: 1. enable non aligned accesses 2. fix code/commands which enables to pass these non aligned addresses which ends up in panic
The patch is targeting option 1 because on arm64 it is permitted.
The same tests were running fine on arm64 where non aligned accesses are permitted.
But I guess they still come under a (severe?) performance penalty?
It is really a question where that penalty is coming from and when it can happen.
It is hard to compare performance impact on u-boot but from functionality point of view we are not able to see difference. If there is any performance impact that it is quite low.
Hm.... I have to admit that I don't know ARM/ARM64 that well, but I am pretty sure that even on ARM an aligned 32 bit access on a 32 bit bus will result in a single read cycle on that bus - while I would expect that an unaligned 32 bit access might get broken down into 4 byte accesses?
I would expect that there will be more cycles for read as you mentioned.
But again the code is align and there is not an issue in code that's why this penalty is not happening. And non align accesses are performed when user asks for this.
Also, I wonder if ARM still maintains atomicity for unaligned reads/ writes ? [IIRC, x86 doesn't, while it's guaranteed for aligned accesses.]
Don't know.
Thanks, Michal