D
Linus Torvalds wrote:
> In article <37764AB6.38EB1D54@netplus.net>,
> Steve Bergman <steve@netplus.net> 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).
>
> Linus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/