Date: Mon, 5 Feb 2001 09:30:18 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
To: Randell Jesup <rjesup@wgate.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: <200102051730.f15HUIU21219@earth.backplane.com>
References: <Pine.LNX.4.21.0102031323080.27128-100000@zeppo.feral.com> <200102040026.f140QuD12547@earth.backplane.com> <ybuelxdnik5.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> (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.
:...
:>
:> 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
I think what's reasonable is to wait until someone - Poul maybe,
puts a better I/O buffering subsytem in place. Anything we do right
now will be a bad hack.
The funny thing about all of this is that we go to great pains to
make things contiguous in KVM, but the bus dma code has to then break
things up into page-by-page DMAs anyway. I'd much rather just hand the
I/O subsystem a list of vm_page_t's without bothering to map them into
KVM.
-Matt
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?200102051730.f15HUIU21219>