From owner-freebsd-arch Sat Feb 3 11:47:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id CD5F537B491; Sat, 3 Feb 2001 11:47:10 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA13387; Sat, 3 Feb 2001 11:46:58 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda13385; Sat Feb 3 11:46:43 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f13Jkaf26424; Sat, 3 Feb 2001 11:46:36 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdt26422; Sat Feb 3 11:46:14 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f13JkBA08356; Sat, 3 Feb 2001 11:46:11 -0800 (PST) Message-Id: <200102031946.f13JkBA08356@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdwA8352; Sat Feb 3 11:45:45 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Matt Dillon Cc: Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-reply-to: Your message of "Wed, 31 Jan 2001 14:08:29 PST." <200101312208.f0VM8Tm17958@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Feb 2001 11:45:44 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101312208.f0VM8Tm17958@earth.backplane.com>, Matt Dillon writes: > > :> Dan Nelson 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