From owner-cvs-sys  Sun Feb 19 18:04:52 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA23516 for cvs-sys-outgoing; Sun, 19 Feb 1995 18:04:52 -0800
Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA23497; Sun, 19 Feb 1995 18:04:39 -0800
Received: from jsdinc.root.com (uucp@localhost) by Root.COM (8.6.8/8.6.5) with UUCP id RAA00958; Sun, 19 Feb 1995 17:15:58 -0800
Received: (root@localhost) by jsdinc (8.6.9/8.6.5) id TAA00246; Sun, 19 Feb 1995 19:58:15 -0500
From: "John S. Dyson" <toor@jsdinc.root.com>
Message-Id: <199502200058.TAA00246@jsdinc>
Subject: Re: cvs commit: src/sys/sys buf.h
To: zeta.org.au!bde@implode.root.com (Bruce Evans)
Date: Sun, 19 Feb 1995 19:58:15 -0500 (EST)
Cc: estienne.cs.berkeley.edu!gibbs@implode.root.com, toor@Root.COM,
        CVS-commiters@freefall.cdrom.com, bde@zeta.org.au,
        bde@freefall.cdrom.com, cvs-sys@freefall.cdrom.com,
        zeta.org.au!toor@implode.root.com
In-Reply-To: <199502192310.KAA05252@godzilla.zeta.org.au> from "Bruce Evans" at Feb 20, 95 10:10:49 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1317      
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

> 
> I think one IDE PIO speed is 3.3M/sec so the time per word is 0.67usec.
> The new EIDE PIO speed of 11M/sec will reduce the problem in a while
> for a while.  I don't see how reducing the I/O size makes any difference
> if the disk+controller can transfer faster than the bus.  Won't the
> driver just loop over more buffers?  There may be short pauses in I/O
> while the drive+controller prepares the next I/O, but only if drive+
> controller didn't do enough read ahead.
> 
I definitely was not suggesting that the current situtation is any better
than the buffer chaining proposal.  Quite the contrary...  But, the point
that I have been trying to make is that we can easily make the problem
worse.

The I/O requests can be structured so that a context switch is required
to queue a new buffer.  The throughput of the system would definitely
be less, but we could improve real-time scheduling performance.  I do
believe that in "normal" systems, we do want to cluster and make the
controller busier.  But in real-time situations it can be counter-productive.

Perhaps, for 2.2+ we could consider re-vamping the kernel for real-time
(or closer to real-time) performance???  Please note, these are somewhat
random thoughts, and right now I have no agenda,  just trying to give
feedback...

John
dyson@root.com