From owner-freebsd-arch  Mon Feb  5 22:58:21 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1F26437B401; Mon,  5 Feb 2001 22:58:04 -0800 (PST)
Received: (from daemon@localhost)
	by smtp05.primenet.com (8.9.3/8.9.3) id XAA25045;
	Mon, 5 Feb 2001 23:53:17 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
 via SMTP by smtp05.primenet.com, id smtpdAAAQuai2W; Mon Feb  5 23:53:09 2001
Received: (from tlambert@localhost)
	by usr08.primenet.com (8.8.5/8.8.5) id XAA12458;
	Mon, 5 Feb 2001 23:57:49 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <200102060657.XAA12458@usr08.primenet.com>
Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386)
To: dillon@earth.backplane.com (Matt Dillon)
Date: Tue, 6 Feb 2001 06:57:48 +0000 (GMT)
Cc: tlambert@primenet.com (Terry Lambert),
	phk@critter.freebsd.dk (Poul-Henning Kamp),
	gibbs@scsiguy.com (Justin T. Gibbs),
	bright@wintelcom.net (Alfred Perlstein),
	rjesup@wgate.com (Randell Jesup), mjacob@feral.com (Matthew Jacob),
	msmith@FreeBSD.ORG (Mike Smith), des@ofug.org (Dag-Erling Smorgrav),
	dnelson@emsphone.com (Dan Nelson),
	tanimura@r.dl.itc.u-tokyo.ac.jp (Seigo Tanimura), arch@FreeBSD.ORG
In-Reply-To: <200102060546.f165kHq58398@earth.backplane.com> from "Matt Dillon" at Feb 05, 2001 09:46:17 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>    I think the idea Poul originally articulated -- having simple information
>    like recommended I/O size, recommended cluster size, and/or maximum I/O
>    size, is the correct solution.  Getting fancy might buy us a percent
>    or two... it isn't worth the effort.

I thought Poul had discarded that idea as unworkable, after having
tried to make it work; I got the impression that he still liked
the idea, but that he didn't have a way to make it practical (Poul,
please correct me if I am misinterpreting your last post).

I can't see hints being much more useful than the seek optimization
code, which was disabled as a pessimization for most ZBR drives,
where the track boundaries were unknown back in the early fictional
geometry days (predating SCSI II, where it could be fixed again).

I would think that you would want your optimization to work at
least 51% of the time for it to be worthwhile, or at least "mostly
harmless", and I really have doubts that "hints" would be able to
do that.

You really don't want to end up with something that makes a
microbenchmark run fast, at the expense of real system loads,
like some of the stuff that happened in the buffer cache code,
historically.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message