On Tue, 2 Feb 2010, Paul E. McKenney wrote: > > One stupid question: why are the hash and length ints rather than shorts? > Doesn't the maximum filename length fit into a 16-bit short? In fact, > doesn't the maximum length of a full pathname fit into a 16-bit short? Yes, the name length could easily be just 16 bits. The hash, though, is a different matter. We actually want lots of bits to spread out the dentries and 16 bits for hashing would be too small (on my machine, the dentry cache hash table has half a million entries and takes 4MB of space - space I'll happily give it to keep the hash chains short). So we need at least 20 bits (and probably more on big machines). Now, we could decide that having just 16 bits for the name hash is enough, because we do mix in the address of the 'parent' dentry, and we might decide that that is worth a few bits (taking the number of total bits up to enough to look up half a million entries) We could also use bitfields, and give the name length say 10 bits, and 22 bits to the hash, which togethr with the extra bits from the parent pointer might well work out fine. It might be worth trying. But is playing that kind of game worth four extra characters in the inline name? If it were to make the difference between "core dentry fields fit in a cacheline" vs "needs two cachelines", then maybe it would be worth it. But I don't think that's the case. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
