On Thu, Feb 04, 2010 at 07:29:25AM -0800, Linus Torvalds wrote: > > > 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. Ah, good point on the hash size. And given that DNAME_INLINE_LEN_MIN is 40 characters on 32-bit systems and 32 characters on 64-bit systems, I agree that while a four-character increase might be nice, it cannot be said to be an emergency. Thanx, Paul -- 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
