Tony Luck wrote:
On Fri, Nov 14, 2008 at 7:26 PM, David Mosberger-Tang <dmosberger@xxxxxxxxx> wrote:In any case, as I remember, the idea was that the kernel would always execute with PSR.AC=1 to avoid silent performance bugs and just since the kernel should be alignment-clean, anyhow. The fys-code doesn't turn on PSR.AC, but I believe the heavy-weight syscall path does. I don't know why head.S turns off PSR.AC. Seems like a bug to me.Running base code and interrupt/trap code with different settings of PSR.ac does sound like a bug ... but the question of what we should set it to deserves a little more thought. Perhaps the best option would be for test & development kernels to set PSR.ac=1 to aid in tracking down any alignment problems in the code. But production kernels should set PSR.ac=0 so that they don't take the cost of a trap on unaligned access that the specific model of processor can handle anyway. If this is the right path, then it should become a CONFIG option.
If the hypothesis is that test and development kernels would catch the alignment problems, then there shouldn't be any in the production kernels right? However, if there _are_ any out there in production don't we want them to become visible? Even on processors which can handle them it is still better to not have the unaligned acesses in the first place right?
rick jones -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|