On Wed, 2018-11-07 at 19:14 +0100, Richard Weinberger wrote: > On Wed, Nov 7, 2018 at 7:05 PM Nikunj Kela (nkela) <nkela@xxxxxxxxx> wrote: > > I had tried to use configs to start with via the following patch however I was advised to have a mount option: > > http://lists.infradead.org/pipermail/linux-mtd/2018-November/085126.html > > Just show performance numbers on how your implementation has an impact or not. > So far your implementation is also not much optimized, maybe likely() > or static keys can help... Using likely() for the native case might help. Static keys might help a little more, but could only work if every file system has the *same* endianness. Unless we end up with three variants, for native vs. swap vs. runtime checking. We also lose a bunch of the optimisations that we gained from using __builtin_swab functions, which let the compiler see what was going on. But we can hypothesise and handwave about it until the cows come home; I'd like to see a real test of whether it actually makes a difference that we care about. If it does, one option might be to just build separate versions of scan.c for each endianness, since that's the critical path we care about.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
