Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Feb 1995 19:58:15 -0500 (EST)
From:      "John S. Dyson" <toor@jsdinc.root.com>
To:        zeta.org.au!bde@implode.root.com (Bruce Evans)
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
Subject:   Re: cvs commit: src/sys/sys buf.h
Message-ID:  <199502200058.TAA00246@jsdinc>
In-Reply-To: <199502192310.KAA05252@godzilla.zeta.org.au> from "Bruce Evans" at Feb 20, 95 10:10:49 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502200058.TAA00246>