Re: [PATCH] Scalable page cache

Daniel Phillips (phillips@bonn-fries.net)
Mon, 26 Nov 2001 21:43:22 +0100


On November 26, 2001 07:16 pm, Benjamin LaHaise wrote:

> 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/