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>