Date: 05 Feb 2001 12:39:59 -0500
From: Randell Jesup <rjesup@wgate.com>
To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
Cc: Matt Dillon <dillon@earth.backplane.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: <ybuae81ni4w.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
In-Reply-To: Cy Schubert - ITSD Open Systems Group's message of "Sat, 03 Feb 2001 11:45:44 -0800"
References: <200102031946.f13JkBA08356@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> writes:
>> 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.
Ok. However, a given machine may be used for either heavy batch
server-style use (say email, DB), or for more interactive work (including
things like serving real-time requests like web pages). Also, usages can
vary over time and load - when there are a bunch of processes accessing the
disk with smallish IO's and/or paging (on that device), we don't want a
large IO tying it up for a while; while when there are few or one process
accessing the channel we probably don't mind running larger requests.
So, the point (as Matt mentioned) is whether any static limit is
appropriate? Or should it be dynamic or at least adjustable? When is a
smaller limit better? When do we want a larger limit? Also, devices
should be able specify higher (or lower) limits, like for SCSI tape
drives.
Personally, I think a dynamic system is preferable, but obviously
more complex. In any case I think it should be adjustable statically.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
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?ybuae81ni4w.fsf>