Date: Sat, 3 Feb 2001 16:26:56 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
To: Matthew Jacob <mjacob@feral.com>
Cc: "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: <200102040026.f140QuD12547@earth.backplane.com>
References: <Pine.LNX.4.21.0102031323080.27128-100000@zeppo.feral.com>
index | next in thread | previous in thread | raw e-mail
: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
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'.
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.
(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.
Increasing DFLTPHYS is not a valid solution.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102040026.f140QuD12547>