It didn't happen with plain 2.2.9... At least I didn't notice it.
> Here a patch against 2.2.9 to fix this bit.
Thanks, I'll try it immediately.
> PS. I had feedback about the new buffer hashfn to be slower than the stock
> one because it takes more time to compute the mul... Did you profiled it?
I profiled the hashfn outside the kernel by putting it into a loop and let
it run several 1000 times. Chuck profiled it inside the kernel. Some ideas:
>--8<--
Is the imul of a K6-2 faster than of a Pentium? I cannot find numbers in
Intel's datasheets. The K6-2 needs 2-3 cycles for a multiplication which
makes the hashfn very fast and efficient. If Intel is so much slower we
really need a platform specific hashfn...
>--8<--
Finding the right buffer in a bucket requires a linear search. The loop in
find_buffer() looks like:
...
<find_buffer+52>: * cmpl %esi,0x8(%eax) if (bh->b_blocknr == block
<find_buffer+55>: * jne 0xc01244dc <+68>
<find_buffer+57>: cmpw %bx,0xc(%eax)
<find_buffer+61>: jne 0xc01244dc <+68>
<find_buffer+63>: cmpl %edi,0x10(%eax)
<find_buffer+66>: je 0xc01244e2 <+74>
<find_buffer+68>: * movl (%eax),%eax bh = bh->b_next
<find_buffer+70>: * testl %eax,%eax for (...; bh; ...)
<find_buffer+72>: * jne 0xc01244cc <+52>
...
If everything is cached it takes at least 3 cycles per loop. A
multiplication should really be faster than the long chains of the old
hashfn.
>--8<--
Maybe an average bucketsize of 8 is too high? This is sufficient with 64MB
since the buffer cache doesn't grow so much anyway. Try reducing it to 4
(The original hashfn has an average bucketsize of 1).
>--8<--
If the problem really is the multiplication, my lightweight-hashfn should
solve the problem:
#define _hashfn(dev,block) \
(((unsigned)((HASHDEV(dev)+block)+(block>>11))) & bh_hash_mask)
It is not designed for best hash distribution. Instead it is designed to be
L1/L2-cache friendly (and of course it avoids the multiplication). Try it
with an average bucketsize of 4 or 2 (8 is too full). If this helps I'll
dig deeper into that kind of hashfn.
>--8<--
At the moment the buffer cache doesn't like to grow much. In fact, it's hard
to get it bigger than 7 MB and it's about 1.5 MB most of the time. Even the
old hashfn should be able to put 1500 buffers into 65536 buckets...
>--8<--
Maybe the original hashfn is good for some type of data (e.g. large
databases) while being bad for other purposes. This can be detected with the
following patch. It applies to your VM1-patch:
--- linux/fs/buffer.c Tue Jun 8 19:28:21 1999
+++ linux-VM1-debug/fs/buffer.c Mon Jun 7 23:52:34 1999
@@ -1509,6 +1509,7 @@
{
struct buffer_head * bh;
int found = 0, locked = 0, dirty = 0, used = 0, lastused = 0;
+ int uc[10], umax = 0;
int protected = 0;
int nlist;
static char *buf_types[NR_LIST] = {"CLEAN","LOCKED","DIRTY"};
@@ -1526,6 +1527,30 @@
*/
if (!spin_trylock(&kernel_flag))
goto no_lock;
+
+ uc[0] = uc[1] = uc[2] = uc[3] = uc[4] = 0;
+ uc[5] = uc[6] = uc[7] = uc[8] = uc[9] = 0;
+
+ for(nlist = 0; nlist <= bh_hash_mask; nlist++) {
+ struct buffer_head * next;
+
+ next = hash_table[nlist];
+ used=0;
+ while (next) {
+ used++;
+ next = next->b_next;
+ }
+ if (umax < used) umax = used;
+ if (used > 9) used = 9;
+ uc[used]++;
+ }
+ printk("Longest list: %6d\n", umax);
+ printk(" List size : empty 1 2 3 4 5 6 7 8 >=9\n");
+ printk(" Num : ");
+ for(nlist = 0; nlist <= 9; nlist++) {
+ printk("%6d ", uc[nlist]);
+ }
+ printk("\n");
for(nlist = 0; nlist < NR_LIST; nlist++) {
found = locked = dirty = used = lastused = protected = 0;
While running a benchmark just type SysRq-M at various checkpoints. Make
sure to use the old hashfn and the new one so the results can be compared.
And please, send some of the results to me.
Peter
--
_ x ___
/ \_/_\_ /,--' p.steiner@t-online.de (Peter Steiner)
\/>'~~~~//
\_____/ signature V0.2 alpha
-
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/