Date: Fri, 3 Dec 1999 09:55:51 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: scsi@FreeBSD.ORG Subject: Re: Tape driver problems Message-ID: <Pine.BSF.4.05.9912030954410.12054-100000@semuta.feral.com> In-Reply-To: <199912031733.KAA11671@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > This particular issue is a defect in the bounce-buffering code; the 1542 > > is limited to 16 or maybe 17 s/g entries. (We allow 17, the Linux driver > > stops at 16.) This isn't an issue for most things until you get up near > > 64k, where fragmentation lets you run out of page-sized entries. I'm not > > sure how best we could work around this without clustering pages in > > bounce-buffer memory. If you've got any neat ideas I'll happily file > > them for next time someone goes looking at that code. > > The bounce buffering code doesn't perform coalessing of data yet because > I never found an algorithm I liked for it. The NetBSD approach of > making the bounce buffer 64K big and copying the whole thing if any > portion needs to be bounced doesn't appeal to me (it doesn't scale > well and consumes much too much memory). You pay for what you get. If you are really still using ISADMA mass storage, blow 128k or MAXPHYS already.. IMO... > Still, I'm surprised > that this is the cause of this particular failure. A kernel malloc > of 64K should return a page aligned chunk of memory. That's a very good point. Maybe something else is happening here. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9912030954410.12054-100000>