hi linus-
On Sun, 30 Jul 2000, Linus Torvalds wrote:
> Btw, from past exprience I've found that it can be a lot more advantageous
> to just dynamically move the hash entries to the front of the list when
> accessed, rather than worry about how the list is set up. Hashes are bad
> on the caches by design, and whether the hash table takes up x or 2x of
> memory is pretty much immaterial for performance. But whether you find
> the entry on the first or the fifth try is noticeable.
>
> I suspect you'd find more of a performance advantage from trying something
> like that instead..
to quote richard dawson during his soused "family feud" period...
"survey says: BZZT!"
the memory store operations required to do LRU list manipulation slow the
search operations down far more than the gains from LRU behavior in the
hash buckets. andrea showed this in his first LRU page patch long ago.
i also measured a slow-down when trying this methodology in the buffer
cache (getblk()).
the best thing to do is shorten your hash chains. use a bigger hash
table, a hash function that randomizes better, or a better bucket data
structure.
executive summary: LRU buckets ain't worth it.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@bigfoot.com>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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:34 EST