Date: Sun, 19 Feb 1995 12:55:02 -0500 (EST) From: "John S. Dyson" <toor@jsdinc.root.com> To: gibbs@estienne.CS.Berkeley.EDU (Justin T. Gibbs) Cc: bde@zeta.org.au, bde@freefall.cdrom.com, CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com Subject: Re: cvs commit: src/sys/sys buf.h Message-ID: <199502191755.MAA00244@jsdinc> In-Reply-To: <199502182250.OAA04194@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Feb 18, 95 02:50:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'd like to see it used as an alternative method for clustering. Any > device doing DMA needs the physical address of pages within a MAXPHYS > buffer, so you end up looping through it. Why bother sticking block > sized buffers into a virtually congious cluster buffer? Why not just link > them together to form the transaction? This also allows controllers like > the 27/28/2942 to do transactions up to 1meg in size (you'd want to limit > it below that to prevent it from hogging the SCSI bus). What would be even > better is some knowledge of what type of device you are talking to so that > if it happens to be PIO, you can give it virtually contiguous chunks of the > right size. > I agree with Justin, we simply "improved" upon the original 4.4 clustering code, but his notion of chained buffers (that he had mentioned to me a couple of months ago) appears to be very good. The code that we currently have has an upper limit of 64K on the cluster size. The problem is that with the current scheme, there is a system wide upper limit. Some devices could probably benefit from increased cluster sizes. However, we might need to be able to tune down the maximum I/O transfer sizes (esp, non bus-mastering stuff), for realtime performance. FreeBSD is being used in a couple of fairly time-critical applications, and it would be nice someday to be able to support nearly real-time (1-5msecs at least) secheduling. Not that we even approach that now (with page table pre-faulting and future IDE multi-block clustering.) All I am saying is that it would be nice to be able to make sure that the new scheme is compatible with pseudo-real-time kernel performance. Perhaps the clustering code is not the right-place to make sure that real-time performance is not further compromised????? John dyson@root.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502191755.MAA00244>