[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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

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
Please read the FAQ at

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