lkml.org 
[lkml]   [2001]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Scalable page cache
Date
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/

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