[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1002040715570.3707@localhost.localdomain>
Date: Thu, 4 Feb 2010 07:29:25 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc: Al Viro <viro@...IV.linux.org.uk>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [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.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists