On 26 Nov 2001, Momchil Velikov wrote:
> Yep. Folks on #kernelnewbies told me about it, when there were only
> changes to ``shrink_cache'' left. So, I decided to funish mine ;)
ok :) A search on Google for 'scalable pagecache' brings you straight to
our patch. I've uploaded the patch against 2.4.16 as well:
http://redhat.com/~mingo/smp-pagecache-patches/pagecache-2.4.16-A1
this is a (tested) port of the patch to the latest VM.
> The tree is per mapping, not a single one. Now, with 16GB cached in a
> single mapping, it'd perform poorly, indeed (though probably not 20).
some databases tend to keep all their stuff in big files. 16 GB ~== 2^22,
thats why i thought 20 was a good approximation of the depth of the tree.
And even with just a depth of 10 per mapping (files with a few megabytes
of size - a totally mainstream thing), the cache footprint per lookup is
still 320 bytes with 32 byte cacheline-size, which is way too big. With
the hash table (page bucket hash table), the typical footprint for a
lookup is just around 2 cachelines, and one of that is a more 'compressed'
data structure.
we really only use trees in cases where it's absolutely necessery. There
mixture data structures of hashes and trees that are beneficial in some
cases, but the pagecache is mostly a random-indexed thing, seldom do we
want to scan adjacent pages. And even in that case, looking up the hash is
very cheap.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:22 EST