Messages in this thread | | | Subject | Re: [PATCH 2.4] jffs2 aligment problems | From | David Woodhouse <> | Date | Mon, 07 Jun 2004 20:14:03 +0100 |
| |
On Mon, 2004-06-07 at 17:41 +0100, Russell King 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.
Admittedly it's not _entirely_ stupid in the network code, because a direct load is often a lot faster than the byte-wise load emitted by get_unaligned(). If alignment is the common case, it makes some sense to optimise that and take the trap only occasionally.
But with uClinux being merged (many uClinux arches can't fix up alignment at all), I think we should revisit that decision.
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.
Or in fact since the ratio between the speeds of the inline and the trap version varies wildly from arch to arch, and hence the point at which it becomes more efficient just to use the current get_unaligned() varies -- perhaps we should have 'get_unaligned(ptr, probability)' and let the arch code decide where the threshold should be. It's not that hard to make it go away completely given __builtin_constant_p(probability) and some preprocessor macros.
-- dwmw2
- 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/
| |