From owner-freebsd-arch Mon Feb 5 9:36: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 6872D37B65D; Mon, 5 Feb 2001 09:35:45 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1LP8YXAJ; Mon, 5 Feb 2001 12:35:38 -0500 Reply-To: Randell Jesup To: Cy Schubert - ITSD Open Systems Group Cc: Matt Dillon , 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) References: <200102031946.f13JkBA08356@cwsys.cwsent.com> From: Randell Jesup Date: 05 Feb 2001 12:39:59 -0500 In-Reply-To: Cy Schubert - ITSD Open Systems Group's message of "Sat, 03 Feb 2001 11:45:44 -0800" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group 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