Re: DVD blockdevice buffers

Alexander Viro (viro@math.psu.edu)
Fri, 25 May 2001 14:24:52 -0400 (EDT)


On Fri, 25 May 2001, Linus Torvalds wrote:

> For example, I suspect that the metadata bitmaps in particular cache so
> well that the fact that we need to do several seeks over them every once
> in a while is a non-issue: we might be happier having the bitmaps in
> memory (and having simpler code), than try to avoid the occasional seeks.
>
> The "simpler code" argument in particular is, I think, a fairly strong
> one. Our current bitmap code is quite horrible, with multiple layers of
> caching (ext2 will explicitly hold references to some blocks, while at the
> same time depending on the buffer cache to cache the other blocks -
> nightmare)

Oh, current code is a complete mess - no arguments here. 8-element LRU.
Combined with the fact that directories allocation tries to get even
distribution of directory inodes by cylinder groups, you blow that LRU
completely on a regular basis if your fs is larger that 16 cg. For 1Kb
blocks fs it's 128Mb. For 4Kb - 2Gb. And pain starts at the half of that
size.

If you are OK with adding two extra arguments to ->readpage() I could
submit a patch replacing that with plain and simple page cache by tomorrow.
It should not be a problem to port, but I want to get some sleep before
testing it...

-
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/