From owner-freebsd-arch  Mon Feb  5 14: 2:23 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6B54937B401; Mon,  5 Feb 2001 14:02:03 -0800 (PST)
Received: from critter (localhost [127.0.0.1])
	by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f15M1gB29136;
	Mon, 5 Feb 2001 23:01:42 +0100 (CET)
	(envelope-from 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) 
In-Reply-To: Your message of "Mon, 05 Feb 2001 13:51:49 PST."
             <20010205135149.G26076@fw.wintelcom.net> 
Date: Mon, 05 Feb 2001 23:01:42 +0100
Message-ID: <29134.981410502@critter>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


>> 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.
>
>I'm not sure I understand what you mean, my vision of the current
>code is:

As others have pointed out, if the requirement that pages be mapped
contiguously for an struct bio request is relaxed, many more clustering
opportunities are expected and some mapping/unmapping operations can
be avoided.

Some argue that it is "some ... many ..." rather than the other
way around.

Either way it should be a gain.

I think it makes sense to try to grab that piece of fruit first,
since it has obvious benefits whereas most of the rest of the
suggestions are in the "pure speculation" range and not testable
without unmapped pages in struct bio.

One way or another, benchmarking will be needed and just what is
a good workload to benchmark on ?  Is make world representative ?
If not, we should establish a reproducible benchmark some other
way.

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