Date: Sat, 03 Feb 2001 11:45:44 -0800
From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To: Matt Dillon <dillon@earth.backplane.com>
Cc: 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: <200102031946.f13JkBA08356@cwsys.cwsent.com>
In-Reply-To: Your message of "Wed, 31 Jan 2001 14:08:29 PST." <200101312208.f0VM8Tm17958@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200101312208.f0VM8Tm17958@earth.backplane.com>, Matt Dillon writes: > > :> Dan Nelson <dnelson@emsphone.com> writes: > :> > On a similar note, is there any reason for us to have DFLTPHYS at 64k > :> > anymore? With the insane interface speeds of SCSI and ATA devices > :> > nowadays, you can easily hit 600 I/Os per second on sequential reads > :> > (40MB/sec, 64K per I/O). Would anything break if MAXPHYS/DFLTPHYS was > :> > bumped to say, 1mb? > :> > :> I think so; we can't do DMA transfers larger than 64k (128k in word > :> mode) - at least for ISA devices, I don't know much about PCI. > : > :It's 128K right now, actually. The problem is that a lot of older > :devices have limits which cap them at 64K. (Typically, 16-bit bytecount > :registers, or 16- or 17-slot scatter/gather tables.) > : [comments deleted] > > 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. If you queue a 1 MByte I/O to a disk device, that disk > device is locked up doing that one I/O for a long time (in cpu-time > terms). Having a large number of bytes queued for I/O on one device > can interfere with the performance of another device. In short, > your performance is not going to get better and could very well get > worse. I remember an IBM MVS course course that made this point abundantly clear. The short of it was that if your system was primarily used as a batch system, e.g. response time didn't matter but throughput did, use large block sizes. If on the other hand your primary workload was time sharing or transaction processing applications, smaller block sizes would improve response times but reduce throughput. Large block sizes tend to monopolise I/O channels. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC 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?200102031946.f13JkBA08356>