[lkml]   [2001]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Scalable page cache

    On Mon, 26 Nov 2001, Benjamin LaHaise wrote:

    > 1. potentially long hash chains are walked with the page cache
    > lock held for the entire duration of the operation

    not the case.

    > 2. multiple cache lines are touched while holding the page cache
    > lock

    not the case because the problem with the pagecache_lock was its bouncing
    between CPUs, not processes waiting on it.

    > 3. sequential lookups involve reaquiring the page cache lock

    the granularity of the pagecache directly influences the number of
    accesses to the pagecache locking mechanizm. Neither patch solves this,
    the number of lock operations does not change - but the lock data
    structures are spread out more.

    i think it's a separate (and just as interesting) issue to decrease the
    granularity of the pagecache - this not only decreases locking (and other
    iteration) costs, it also decreases the size of the hash (or whatever
    other data structure is used).

    > 4. the page cache hash is too large, virtually assuring that
    > lookups will cause a cache miss

    this does not appear to be the case (see my other replies). Even if the
    hash table is big and assuming the worst-case (we miss on every hash table
    access), mem_map is *way* bigger in the cache because it has a much less
    compressed format. The compression ratio between mem_map[] and the hash
    table is 1:8 in the stock kernel, 1:4 with the page buckets patch.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:13    [W:0.021 / U:74.236 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site