[lkml]   [2010]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][RFC] %pd - for printing dentry name

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.


 \ /
  Last update: 2010-02-04 16:31    [W:0.056 / U:2.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site