Date: Wed, 26 Feb 2003 08:58:38 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Thomas Moestl <tmoestl@gmx.net>, Maxime Henrion <mux@FreeBSD.org> Cc: 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: <508522704.1046275118@aslan.scsiguy.com> In-Reply-To: <20030226124632.GA631@crow.dom2ip.de> References: <200302260216.h1Q2G6UK033030@repoman.freebsd.org> <20030226124632.GA631@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> Users of the busdma interface should use realistic sizes and for the > maxsize argument to bus_dma_tag_create(), since tag creation can in > fact result in bounce buffer allocation (or e.g. DVMA allocation), so > excessive sizes will just suck up resources, and this constant was a > useful hint (while the new one might be used for maxsegsz like the > old one could be too, but should not be for maxsize). Allocating backing store in bus_dma_tag_create() is extremely unwise unless the ALLOC_NOW flag is provided. Consider a tag that is simply a placeholder in the hierarchy of tags from root bus to the end device. This tag may be for a bridge that can handle any size up to MAXSIZE_32BIT, but will never allocate any dmamaps or memory directly against its own tag. Using a large size is, in effect, indicating "no restriction" for the size parameter due to this particular device. If the implementation has some other limitation, place it in the root bus's tag and allow inheritance to do the rest. Tags that have maps created for them should have sane sizes specified for them. > While some implementations did not stricly enforce that limit in the > non-__GNUC__ case, it was still mostly correct, as it is arbitrary > except for the stack space and bounce buffer usage in some places in > those busdma implementations; if we can tolerate memory usage there > BUS_SPACE_MAXSIZE could as well have been increased. The stack space usage will soon be replaced by allocating the segment array on the heap and attaching it to the tag. > This change also breaks the sparc64 IOMMU code, which relied on the > old semantics for it's preallocation clamping code. I would expect that DVMA allocation has to occur (up to some limit) with every bus dmamap that is allocated against a tag. Is there some reason that all allocations cannot occur in this fashion? Does the Sparc64 implementation even allow blocking for resources and doing a deferred callback so you don't have to allocate for all requests? -- Justin 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?508522704.1046275118>