Date: Mon, 05 Feb 2001 22:33:36 +0100
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, Randell Jesup <rjesup@wgate.com>, Matt Dillon <dillon@earth.backplane.com>, Matthew Jacob <mjacob@feral.com>, Mike Smith <msmith@FreeBSD.ORG>, Dag-Erling Smorgrav <des@ofug.org>, Dan Nelson <dnelson@emsphone.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, arch@FreeBSD.ORG
Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386)
Message-ID: <28962.981408816@critter>
In-Reply-To: Your message of "Mon, 05 Feb 2001 13:21:52 PST." <20010205132152.E26076@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>You're right, it's non-trivial, however the difference between >memory and disk speed is also non-trivial, almost every reasonable >algorithm should be considered to reduce/optimize disk traffic. > >A simple call into the VFS should be able to accomplish, afaik when >a VFS has a disk/physical backing it also hashes/sorts bufs based >on physicall backing location. Although I may be remebering stuff >from 4.3BSD or 4.4BSD instead of the current code... It's not "a simple call". By the time you can make the call, you have passed through the target FS, through specfs and the disklabel/slice code, possibly through a layer like vinum and ccd (which may have their own ideas about clustering) and only then do you arrive at a place where you know the actual sector address of the request. We can quickly dismiss the ccd/vinum case by saying that they have to cater for the needs of the lower devices, and they specify the clustering policy "like any other disk". But you still have to contend with the diskslice/label code, and specfs, so even if you do an "upcall" and find more stuff you can read/write, you need to pass this bit of the request down through the specfs (for softupdates rollback/forward) and diskslice/label code (because you want boundary checking). And having tried that, I can say with 100% conviction: that is not an sane option, and if you do it anyway you will certainly not gain any performance by the time you have resolved all the locking issues. Giving some kind of abstract hint from the driver/device and making the clustering optional for the driver is the only path which does not lead straight down to layering insanity. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28962.981408816>