From owner-freebsd-arch@FreeBSD.ORG Sat Jun 28 14:33:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC18C37B401; Sat, 28 Jun 2003 14:33:26 -0700 (PDT) Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F50144001; Sat, 28 Jun 2003 14:33:25 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.9/8.12.8) with ESMTP id h5SLXPEU046677; Sat, 28 Jun 2003 15:33:25 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Sat, 28 Jun 2003 15:33:25 -0600 From: "Justin T. Gibbs" To: Scott Long , John Baldwin Message-ID: <2768600000.1056836005@aslan.scsiguy.com> In-Reply-To: <3EFDC2EF.1060807@freebsd.org> References: <3EFDC2EF.1060807@freebsd.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 21:33:27 -0000 > Ok, after many semi-private discussions, how about this: There is only one problem with this strategy. The original idea of using a mutex allowed the busdma API to use that same mutex as the strategy for locking the fields of the tag, dmamap, etc. In other-words, the agreement would have been that the caller always has the lock held before calling into bus dma, so that bus dma only has to grab additional locks to protect data shared with other clients. For this to work in the more general scheme, you would have to register "acquire lock"/"release lock" functions in the tag since locking within the callback does not allow for the protection of the tag or dmamap fields in the deferred case (they would only be protected *during* the callback). Again, what we want to achieve is as few lock acquires and releases in the common case as possible. For architectures like x86, the only data structure that needs to be locked for the common case of no deferral and no bounce page allocations is the tag (it will soon hold the S/G list passed to the callback). Other implementations may need to acquire other locks, but using the client's lock still removes one lock acquire and release in each invocation that is not deferred. -- Justin