Messages in this thread | | | Date | Mon, 7 Jun 2004 12:22:57 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH 2.4] jffs2 aligment problems |
| |
On Mon, 7 Jun 2004, David Woodhouse wrote: > > > Pleas fix jffs2 to use the proper "get_unaligned()"/"put_unaligned()" > > > instead. > > > I'll let you have a bun fight with dwmw2 and networking people over > > this. I'm standing well clear. 8) > > S'fine by me. I already added get_unaligned() to the flash drivers years > ago -- it's actually those, not JFFS2 itself which needs it. Alan > insisted I remove it on the basis that much of our network code is > similarly broken anyway; an arch without fixups is dead in the water > whatever happens.
I don't see it as a correctness issue, I see it as a performance issue.
Yes, the old ARM chips that can't do unaligned accesses and can't even trap on them probably have a number of cases where they literally do the wrong thing, and I think most people will say "tough luck, don't do that then".
But get_unaligned() makes sense quite apart from that usage too. Notably, many architectures can cheaply do unaligned accesses when they are known to be unaligned, but take thousands of cycles to fix up traps. Alpha comes to mind, and this was actually what "get_unaligned()" was really designed for.
> Anything which _could_ be unaligned should be marked as such, even if we > do have two levels ('possibly unaligned', 'probably unaligned') where > the latter behaves purely as an optimisation on most arches, just like > our current get_unaligned() does.
Right now we might as well consider the "get_unaligned()" to be a "quite possibly unaligned" as opposed to "this just _might_ be unaligned".
That's the current usage pattern anyway. Nothing really _guarantees_ that unaligned accesses are marked with "get_unaligned()", but the unaligned fixup is at least supposed to be _rare_.
Put another way: imagine if the unaligned handler did a printk(). That shouldn't flood the logs under normal load.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |