Date: Wed, 27 Mar 1996 11:28:53 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: davidg@Root.COM Cc: hackers@freefall.freebsd.org Subject: Re: Can't read this stupid DAT tape - ARGH! Message-ID: <199603271928.LAA20282@freefall.freebsd.org> In-Reply-To: Your message of "Tue, 26 Mar 1996 17:17:42 PST." <199603270117.RAA10049@Root.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>j@uriah 268% fgrep MAXPHYS /usr/include/machine/* >>>/usr/include/machine/param.h:#define MAXPHYS (64 * 1024) /* m >ax >>> raw I/O transfer size */ >>> >>>I think you gotta bump this one to 256 K, and recompile your world. >> >>Buffers only hold 64k. How can you read a larger block size? We have to >>provide a way of chaining buffers together to allow such large block sizes. >>I proposed buffer chaining to John some time ago, but other things have >>been more important. > > The buffer size could be increased, but the larger problem is that most if >not all of the adapters have too few scatter-gather segments to handle it. In >order to work around this, we'd have to implement some general mechanism for >allocating contiguous chunks of memory that works all the time (as opposed to >just during startup like the current code does). This is very difficult >because it involves reclaiming pages/paging. > >-DG Wouldn't it cost too much kernel VM to increase MAXPHYS? With buffer chaining, and the ability to maintain buffers that were composed of chunks of contiguous space (16k, 32k, the whole buffer?) it would be easier to "reclaim space" and still get the SG count for large "256k" transactions down to something reasonalbe. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603271928.LAA20282>