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/