Date: Mon, 5 Feb 2001 14:50:04 -0800 (PST)
From: Matthew Jacob <mjacob@feral.com>
To: Chuck Paterson <cp@bsdi.com>
Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Alfred Perlstein <bright@wintelcom.net>, Randell Jesup <rjesup@wgate.com>, Matt Dillon <dillon@earth.backplane.com>, Mike Smith <msmith@FreeBSD.ORG>, Dag-Erling Smorgrav <des@ofug.org>, Dan Nelson <dnelson@emsphone.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, arch@FreeBSD.ORG
Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386)
Message-ID: <Pine.LNX.4.21.0102051442410.3402-100000@zeppo.feral.com>
In-Reply-To: <200102052234.f15MYfW96817@grendel.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Feb 2001, Chuck Paterson wrote: > In the discussions I noticed someone mentioned some > of the issues with architectures like Sparc. I haven't noticed > anyone discuss the need to deal with the limited DVMA space. You > really need to have some reservation policy on the buffer before > you send them down to a driver, or at least have the > driver do a call to get a reservatioin commitment before > actually doing the map ins. If not you could have problems > like two drivers trying to map there io buffer, both having them > half mapped and unable to get the resouces to finish the mapping. True enough- but this is true for a single process that needs to map more than any specific limited resource- so it isn't just two processes getting deadlocked. That's specifically why a 'mapping window' approach was added to the Solaris DDI DMA model- this allowed one to do a dma transfer for darn near all of physical memory as long as you had a device that could shift the mapping window as needed during the transfer (yes, I actually did test it- it was *wierd* doing 28MB 'single' dma transfers on a Sparc2). From a more or less practical point of view, the newer Ultra machines have a programmable iommu that allows you to pretty much map up to a gig of memory. Then it becomes a very very interesting dance using full, uh, 36 bit I think, physical address and some undefined stuff about I/O coherencey in that case. I'll assert that FreeBSD, should it do a sparc port, shouldn't have the slightest interest in anything less than this class of machines. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0102051442410.3402-100000>