On Mon, Feb 5, 2018 at 7:36 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Feb 5, 2018 at 9:32 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> >> Assuming the fix is not moronic, I wouldn't even know where to begin testing >> its affects, or how to prove if there really is a problem. >> Any suggestions? > > So I *think* that this was on purpose, but it's a long time ago, and > we've changed some of the hashing since. > > And I think you're wrong that it's a no-op on 32-bit. It's a very > expensive and pointless multiplication there too, even if the *shift* > ends up being a nop-op. > I did not mean this is no-op on 32-bit, what I meant is that the patch changes nothing for 32-bit long, besides the zero shift, because: #if BITS_PER_LONG == 32 #define hash_long(val, bits) hash_32(val, bits) and hash_32_generic() is just __hash_32() with zero shift. I guess I cannot make that claim for platforms that HAVE_ARCH_HASH_32. > The name hashing is pretty performance-sensitive. > I realize that, that's why I am asking. BTW, I think this shouldn't affect dcache on x86_64 and arm64, because they use the CONFIG_DCACHE_WORD_ACCESS variant of full_name_hash(). Anyway, my work does not depend on this fix, so I am fine with leaving it be. I just wanted to point it out is case you knew what the original intention was. Thanks, Amir.
