From owner-cvs-all Wed Feb 26 7:59:49 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1826D37B401; Wed, 26 Feb 2003 07:59:47 -0800 (PST) Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A8E243F3F; Wed, 26 Feb 2003 07:59:44 -0800 (PST) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.6/8.12.5) with ESMTP id h1QFwcOU081751; Wed, 26 Feb 2003 08:58:38 -0700 (MST) (envelope-from gibbs@scsiguy.com) Date: Wed, 26 Feb 2003 08:58:38 -0700 From: "Justin T. Gibbs" To: Thomas Moestl , Maxime Henrion 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> X-Mailer: Mulberry/3.0.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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-all" in the body of the message