Date: Wed, 26 Feb 2003 23:03:25 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Maxime Henrion <mux@freebsd.org>, src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/include bus.h src/sys/i386/i386 busdma_machdep.c src/sys/i386/include bus_at386.h bus_pc98.h src/sys/ia64/ia64 busdma_machdep.c src/sys/ia64/include bus.h src/sys/powerpc/include bus.h ... Message-ID: <20030226220325.GA676@crow.dom2ip.de> In-Reply-To: <718290000.1046281263@aslan.btc.adaptec.com> References: <200302260216.h1Q2G6UK033030@repoman.freebsd.org> <20030226124632.GA631@crow.dom2ip.de> <508522704.1046275118@aslan.scsiguy.com> <20030226165116.GC631@crow.dom2ip.de> <718290000.1046281263@aslan.btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2003/02/26 at 10:41:04 -0700, Justin T. Gibbs wrote: > > Yes, that was what I was meaning to say. However if a parent tag is > > meant to impose no restriction above the default at all, the maximum > > supported size may as well be used. > > I disagree. The tags for bridges, etc. should document the capabilities > of the hardware, not the underlying implementation. For example, if the > hardware can support a 32bit count it should say so. The implementer > of the tag shouldn't need to know if the limit they are imposing is greater > or less than the implementation's limit. That is why using BUS_SPACE_MAXSIZE > is rarely correct if used to describe a tag for real hardware. OK, I can see how this is more elegant; however, I still think that the implementation's limit could be useful for some consumers. When the tag hierarchy bug mentioned below is fixed, the proper way is probably to retrieve it from the tag in some way. My initial criticism was mainly because the (apparent, since one can only judge from the code and comments) semantics of this constant was changed. On second thought, it seems to not have been widely used, so that probably does not matter much. > > Maximum sizes specified for parent tags seem not to be honored by any > > implementation anyway. > > That, just like the BUS_SPACE_MAXSIZE issue, is a bug in the implementation. OK. > > However, many busdma users specify > > tag sizes that are much larger than any map that they are going to > > load, or need many maps which may be as large as the maximum size > > indicates, but usually are not, so we are running out of DVMA too > > quickly. Therefore, preallocation is clamped to a certain amount of > > DVMA, and failures are ignored silently at map creation time. When the > > map is to be loaded and an insufficient amount of DVMA is allocated > > for the map, reallocation is tried, stealing DVMA from currently > > unloaded maps if necessary (and using the current request size as a > > better approximation of how much is needed). Unloaded maps keep their > > DVMA (unless it's stolen) until they are destroyed. > > This seems to work quite well in practice, reallocations at load time > > are very rare under normal load; if it proved to be a problem at some > > point, additional tuning would likely make it acceptable again. > > This scheme seems somewhat similar to the x86 bounce scheme with a few, > perhaps unecessary?, complications. Why keep DVMA associated with > inactive maps at all? Why not just always allocate the DVMA from > a common pool at load time and avoid the complicated "steeling > scheme"? Because for some operations contiguous slabs of DVMA are required or prefered, and alignments and boundaries need to be honored in some cases (e.g. loading bus_dmamem_alloc()ed maps). This makes implementing such a pool more complex than bounce page management; additionally, this would introduce some situations which might be undesirable and would require additional handling, e.g. avoiding to hand out slabs that are aligned more strictly as required unnecessarily, since they are harder to come by. In summary, I think that the current code is probably at least not more complex than a pool method, and potentially more efficient. - Thomas -- Thomas Moestl <tmoestl@gmx.net> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030226220325.GA676>