From owner-freebsd-arch Mon Feb 5 9:26:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id AC9BA37B503; Mon, 5 Feb 2001 09:26:29 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1LP8YWWG; Mon, 5 Feb 2001 12:26:29 -0500 Reply-To: Randell Jesup To: Matt Dillon Cc: Matthew Jacob , "Justin T. Gibbs" , 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) References: <200102040026.f140QuD12547@earth.backplane.com> From: Randell Jesup Date: 05 Feb 2001 12:30:50 -0500 In-Reply-To: Matt Dillon's message of "Sat, 3 Feb 2001 16:26:56 -0800 (PST)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon writes: > This is a reasonable criticism, but putting aside the issue of bloating > kernel stack useage from huge struct buf structures there is also the > issue of whether any static limit is 'reasonable'. Good point. > The device driver API supports arbitrary raw read and raw write > sizes, but nearly all the device drivers convert read() and write() > calls to physio() calls, and those then convert the parameters > to struct buf / VOP_STRATEGY() calls. > > There are only two solutions that I can see: > > (1) have the SCSI tape device code not convert raw reads and writes > to VOP_STRATEGY calls and instead manage the KVA for the I/O via some > other mechanism. This seems rather painful and makes support for large IO's very driver-dependant and confusing. > (2) Modify the 'struct buf' b_pages[] array to instead be a pointer > to an array. Include the original static array under another name > for compatibility purposes and have the init code default to > assigning b_pages to the original embedded static array. > > Then the physio code could be adjusted to dynamically MALLOC the > necessary pages array if the static one in the supplied buffer is > insufficient. So, how reasonable is this? It seems like a pretty good solution, but I'm far from up-to-speed on the internals here. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message