lkml.org 
[lkml]   [1999]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] hashtable sizes for icache and dcache
andrea-

i have a patch which allocates these tables dynamically, just as is done
in the page and buffer caches. i've posted it here several times, but it
was never applied to any official kernel (i don't know why). i was told
that static increases such as you are proposing would be inappropriate for
machines with small physical memory.

increasing the sizes of these tables is an easy and significant
performance win.

On Wed, 22 Sep 1999, Andrea Arcangeli wrote:

> Date: Wed, 22 Sep 1999 16:06:10 +0200 (CEST)
> From: Andrea Arcangeli <andrea@suse.de>
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>, Chuck Lever <cel@monkey.org>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: [patch] hashtable sizes for icache and dcache
>
> 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
>
>

- Chuck Lever
--
corporate: <chuckl@netscape.com>
personal: <chucklever@netscape.net> or <cel@monkey.org>

The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.068 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site