Date: Mon, 28 Oct 2002 00:04:00 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bruce Evans <bde@zeta.org.au> Cc: Seigo Tanimura <tanimura@axe-inc.co.jp>, Julian Elischer <julian@elischer.org>, Jeff Roberson <jroberson@chesapeake.net>, <current@FreeBSD.ORG>, <tanimura@FreeBSD.ORG> Subject: Re: Dynamic growth of the buffer and buffer page reclaim Message-ID: <200210280804.g9S840nN094111@apollo.backplane.com> References: <20021028181505.K14172-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmm. Well, the real problem is not going to be the struct bio
but will instead be the filesystem support. Filesystems expect
KVA mapped data from the buffer cache, and they use pointers
to the data all over the place.
The buffer cache is very efficient, at least as long
filesystem block sizes are <= 16K. You can mix filesystem
block sizes as long as they are <= 16K and there will
be no remapping and no fragmentation and buffer cache
operation will be O(1). If you mix filesystem block
sizes <= 16K and > 16K the buffer cache will start to hit
remapping and fragmentation cases (though its really
the remapping cases that hurt). It isn't a terrible
problem, but it is an issue.
Tor has test cases for the above issue and could probably
give you more information on it.
The real performance problem is the fact that the buffer
cache exists at all. I wouldn't bother fixing the remapping
issue and would instead focus on getting rid of the buffer
cache entirely. As I said, the issue there is filesystem
block mapping support for meta-data (bitmaps, inodes), not I/O.
-Matt
Matthew Dillon
<dillon@backplane.com>
:On Mon, 28 Oct 2002, Seigo Tanimura wrote:
:
:> On Thu, 24 Oct 2002 15:05:30 +1000 (EST),
:> Bruce Evans <bde@zeta.org.au> said:
:>
:> bde> Almost exactly what we have. It turns out to be not very good, at least
:> bde> in its current implementation, since remapping is too expensive. Things
:> bde> work OK to the extent that remapping is not required, but so would a
:> bde> much simpler implementation that uses less vm and more copying of data
:> bde> (copying seems to be faster than remapping).
:>
:> Which process is expensive in remapping? Allocation of a KVA space?
:> Page wiring? Or pmap operation?
:
:The allocation seemed to be most expensive when I looked at this about 2
:years ago. The cause of the remapping seemed to be that different amounts
:of buffer kva were allocated for different buffer sizes. Copying between
:filesystems with different block sizes therefore caused lots of remapping.
:I think this cause of remapping has been fixed. VM has been improved too.
:I'm not sure how much in this area.
:
:Bruce
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210280804.g9S840nN094111>