[lkml]   [1999]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Status of the buffer cache in 2.3.7+
    In article <>,
    Steve Bergman <> wrote:
    >Forgive me if this seems a really dense question, but with the new
    >unified page cache, is the buffer cache completely obsolete? There is
    >still a number for it in top and vmstat (which comes from /proc, I
    >suppose) which seems to increase practically without bound as block
    >devices are read. I assume the number is bogus now.

    The old buffer cache is still used for meta-data: the page cache only
    handles "real" file data.

    We may at some point map meta-data too in the page cache (others have
    done so), but there really isn't all that much point to it. The buffer
    cache does exactly the right thing for meta-data.

    >Also, I am trying to understand how much difference this actually makes
    >as far as memory usage is concerned. On a "typical system" (yeah, right
    >;-) how much duplication of cache was really occurring. And is this
    >significant for low memory systems as well as large memory ones?

    The cache duplication under "normal" load was often basically zero.

    However, what is "normal" to some people is not normal to others. There
    are lots of real cases where the cache duplication was a major problem.
    In many cases you could never tell, but then occasionally there were
    really bad cases.

    Also, the new code not only gets rid of the duplication, it also cleans
    up a lot of stuff that was rather ugly before. Shared writable mappings
    are squeaky clean - and they sure as h*ll did not use to be that way ;).
    So there are more "conceptual" reasons why the new code is just
    infinitely preferable to the old code.

    The new code also scales much better under load and on SMP. The old
    code could probably have been made to scale too, but it was much easier
    with the page cache, as the page cache has a much clearer abstraction.
    Even so, it was a major project, and Ingo did a _lot_ of heavy lifting
    (on the kernel mailing list you mainly see the arguments about how it
    should be done, so don't get them wrong: Ingo has been doing some
    outstanding work to get it all working so cleanly).


    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:52    [W:0.021 / U:0.908 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site