lkml.org 
[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PFC]: hash instrumentation
On Wed, 14 Apr 1999, Stephen C. Tweedie wrote:

>Shrinking the dcaches excessively in this case will simply masaccre the
>performance. Apparently glibc-2.1 is a particularly heavy test of

In my kernel shrink_mmap() will never fail until you are so low on cache
that you need to swapout. So with high memory machines this is _not_ an
issue at _all_. It can be an issue in low memory machines where we are
used to swapout all the time but in such case I think that having an
unlimited dcache may hurt too. This is the point of my change. My point is
that swap_out() is really not going to fail easily while swapping out not
too much heavily (as during normal operations with a low memory machine).

And btw, maybe dlookup was too much slow because the dhash was too much
populated...

BTW, I have just an experimental kernel running with per-inode rb-trees in
the page cache. I still have to fix my rb_erase (right now it crashes but
I know exactly why ;), when it will be stable I'll post a patch asking for
benchmarks ;). Maybe it will lose, but it was too fun to not implement it
at once ;).

I am also very happy to hear that using the mul-method the hash function
is far better distributed. For thing like icache where there is a fixed
number of entries in the cache, an hash function is sure better than
trees. But I think that for 64 bit machines the mul-hashfunction has to be
changed. We must multiply sqrt(5)... for 2^64 and not for 2^32 as now
etc... At least this is what I understood by the math.

Andrea Arcangeli


-
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:51    [W:0.061 / U:3.020 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site