[patch] hashtable sizes for icache and dcache

Andrea Arcangeli (andrea@suse.de)
Wed, 22 Sep 1999 16:06:10 +0200 (CEST)


As with my inode-dynamic patch I can alloc in icache more than 100000
inodes and so using a 256 wide hashtable for the lookups is really too
small. The profiling numbers become really bad in find_inode under lots of
inode load.

Also the dcache can grow a lot more easily (previously it could grow too
to insane heavy numbers but only by using hard links).

So basically I propose this patch as I think it can be useful also
to the stock kernel to get better performances. It increase the ihash size
from 256 buckets to 16000 buckets that means 131k for the ihash. I enalrged also
the dhash from 1024 buckets to 16000 buckets as there are really lots of
hash entries.

I believe it doesn't worth to save 200k of RAM and to go slow (note
the binary image won't bloat as the hash is allocated in the .bss
section).

--- 2.3.18ac7/fs/inode.c Tue Sep 14 14:35:13 1999
+++ /tmp/inode.c Wed Sep 22 00:31:32 1999
@@ -28,7 +28,7 @@
* Inode lookup is no longer as critical as it used to be:
* most of the lookups are going to be through the dcache.
*/
-#define HASH_BITS 8
+#define HASH_BITS 14
#define HASH_SIZE (1UL << HASH_BITS)
#define HASH_MASK (HASH_SIZE-1)

--- 2.3.18ac7/fs/dcache.c Tue Sep 14 14:35:13 1999
+++ /tmp/dcache.c Wed Sep 22 00:31:47 1999
@@ -42,7 +42,7 @@
* This hash-function tries to avoid losing too many bits of hash
* information, yet avoid using a prime hash-size or similar.
*/
-#define D_HASHBITS 10
+#define D_HASHBITS 14
#define D_HASHSIZE (1UL << D_HASHBITS)
#define D_HASHMASK (D_HASHSIZE-1)

With this patch applyed I can handle up to 100000 files at an amazing fast
speed:

andrea@laser:~/kernel > time (find 2.3.18ac7/ | wc -l ; cp -al 2.3.18ac7 tmp; rm -rf tmp)
5842

real 0m0.520s
user 0m0.090s
sys 0m0.430s

Doing the above I had only 23000 inodes allocated in the dcache though...

andrea@laser:~/kernel > cat /proc/slabinfo | grep inode
inode_cache 23652 23928

and the find_inode and d_lookup are in the middle of the profiling
numbers so they doesn't harm performances at all with the larger hash
(while with 100000 inodes they was the first hit in the profiling).

If you want to merge the inode-dynamic the latest patch against 2.3.18ac7
is here:

ftp://ftp.suse.com/pub/people/andrea/kernel-patches/my-2.3.18ac7/inode-dynamic-4

It always worked like a charm here.

Andrea

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/