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. -Tony -- 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
|