From owner-freebsd-arch Sat Feb 3 13:23:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6CF0337B65D; Sat, 3 Feb 2001 13:23:30 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA30330; Sat, 3 Feb 2001 13:23:17 -0800 Date: Sat, 3 Feb 2001 13:23:14 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: Matt Dillon , Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-Reply-To: <200102032103.f13L3nO55354@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thank you. You put it exactly right. > > And, finally, while large I/O's may seem to be a good idea, they can > > actually interfere with the time-share mechanisms that smooth system > > operation. > > Large I/Os, while interesting for disks, are often *required* for dealing > with non-disk devices. If I want to read a tape generated from an SGI, > for example, the records may be 1MB in size. Almost all of our PCI SCSI > controllers can perform such a large I/O, but DFLTPHYS prevents you from > servicing such an I/O. On devices like tape, you can't break up the I/O > to the device into chunks smaller than the block size. We *need* a way > to perform I/Os that span more than one buffer so we can avoid the DFLTPHYS > limit. > > -- > Justin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message