From owner-freebsd-arch@FreeBSD.ORG Sun Jun 29 09:57:38 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 1104337B401; Sun, 29 Jun 2003 09:57:38 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21B0F44003; Sun, 29 Jun 2003 09:57:37 -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 h5TGvaEU049215; Sun, 29 Jun 2003 10:57:36 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Sun, 29 Jun 2003 10:57:36 -0600 From: "Justin T. Gibbs" To: Scott Long Message-ID: <2947280000.1056905856@aslan.scsiguy.com> In-Reply-To: <3EFE48E8.1040700@freebsd.org> References: <3EFDC2EF.1060807@freebsd.org> <2768600000.1056836005@aslan.scsiguy.com> <3EFE48E8.1040700@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: Sun, 29 Jun 2003 16:57:38 -0000 >> 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 > > This is becoming wonderfully complex. What is the purpose of storing > the S/G list in the tag? Are we going to enforce a 1:1 relationship > between tags and maps? That would really suck for the aac(4) driver. No. We are going to enforce only one callback invocation at a time per tag. The S/G list is only persistent for the lifetime of the callback. The reason for the change is to avoid using the stack for large S/G lists. -- Justin