From owner-freebsd-arch  Sat Feb  3 16:27:18 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP
	id 44DC037B503; Sat,  3 Feb 2001 16:26:59 -0800 (PST)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.1/8.9.3) id f140QuD12547;
	Sat, 3 Feb 2001 16:26:56 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 3 Feb 2001 16:26:56 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200102040026.f140QuD12547@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) 
References:  <Pine.LNX.4.21.0102031323080.27128-100000@zeppo.feral.com>
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

    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