> First off, if we take a look at why the page cache lock is being contended
> a few obvious problems pop out immediately:
>
> 1. potentially long hash chains are walked with the page cache
> lock held for the entire duration of the operation
Yes, having a not-very-random hash function makes this worse. What we see
is: the attempt to improve locality by having the hash function preserve
certain input bits can easily produce a net loss by causing a big variance in
hash chain length, increasing the average length of the list walk. At some
point I'll go check this theory for the pache cache (in fact I think it's
already been checked, and a paper written about it).
> 2. multiple cache lines are touched while holding the page cache
> lock
> 3. sequential lookups involve reaquiring the page cache lock
> 4. the page cache hash is too large, virtually assuring that
> lookups will cause a cache miss
A more random hash improves (4) too, by allowing a smaller table.
Though somebody may well come up with a better structure than a hash table
for the page cache, I'm pretty sure we can make the existing approach work a
little better.
We could divide up the locking using pcache_locks [page_hash >> some_shift].
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/