Re: [PATCH][RFC] %pd - for printing dentry name

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

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