Date: 05 Feb 2001 12:30:50 -0500
From: Randell Jesup <rjesup@wgate.com>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: Matthew Jacob <mjacob@feral.com>, "Justin T. Gibbs" <gibbs@scsiguy.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: <ybuelxdnik5.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
In-Reply-To: Matt Dillon's message of "Sat, 3 Feb 2001 16:26:56 -0800 (PST)"
References: <Pine.LNX.4.21.0102031323080.27128-100000@zeppo.feral.com> <200102040026.f140QuD12547@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon <dillon@earth.backplane.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybuelxdnik5.fsf>