From owner-freebsd-current Mon Oct 28 0: 4:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 919BA37B401; Mon, 28 Oct 2002 00:04:13 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C8D943E4A; Mon, 28 Oct 2002 00:04:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id g9S841FC094114; Mon, 28 Oct 2002 00:04:01 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id g9S840nN094111; Mon, 28 Oct 2002 00:04:00 -0800 (PST) (envelope-from dillon) Date: Mon, 28 Oct 2002 00:04:00 -0800 (PST) From: Matthew Dillon Message-Id: <200210280804.g9S840nN094111@apollo.backplane.com> To: Bruce Evans Cc: Seigo Tanimura , Julian Elischer , Jeff Roberson , , Subject: Re: Dynamic growth of the buffer and buffer page reclaim References: <20021028181505.K14172-100000@gamplex.bde.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 :On Mon, 28 Oct 2002, Seigo Tanimura wrote: : :> On Thu, 24 Oct 2002 15:05:30 +1000 (EST), :> Bruce Evans 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