[lkml]   [1999]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: arca-vm-26
       Date: Thu, 21 Jan 1999 12:22:10 +0100 (CET)
    From: Andrea Arcangeli <>

    Really I think that for the long run I should start dropping the
    cache and buffer hashes replacing them with RB-trees to work fine
    everywhere without waste some base memory with fuzzy hash tables. I
    think that doing that everything should scale _far_ better also
    under the scenario you are describing.

    Comments from David? (note RB-trees != AVL ;).

    If the page cache hash was 1 chain per system page, people would eat
    memory scaled to how much memory they have. And you approach ~O(1)
    access time with a not-too-stupid hash. At worst you eat a cache line
    miss, and this is service on the order of 24 cpu cycles on most modern
    machines where you'd have a lot of memory so...

    Anyways, thats my position, and I'd be thinking about this sort of
    stuff for 2.3.x, not now.

    Another stupid idea I had, which wasted a lot of memory but could
    remove a lot of buffer.c code and make things snappier, put
    MAX_BUF_PER_PAGE buffer heads at the end of struct page, use them when
    doing page I/O. Zero race conditions, no funny buffer unused and
    reclaim list races and synchronization, etc. Also each of these
    static per-page buffer heads have the appropriate pointers and some
    other state setup already, so you don't need to do much to get an I/O
    out the door.

    But like I said, this is stupid, especially right now because the
    buffer head structure is a little sizable. If someone trimmed them
    down a lot and perhaps changed them to really be "I/O tags" then this
    scheme may make more sense. Even nicer would be if these I/O tags
    used an iovec[] so a lot of state is redundant in the page I/O case,
    hint hint :-)

    David S. Miller

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

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