Messages in this thread | | | Date | Wed, 14 Apr 1999 15:06:28 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [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/
| |