From owner-freebsd-arch@FreeBSD.ORG Tue Apr 28 22:27:44 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 117655C9; Tue, 28 Apr 2015 22:27:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE5EA1F35; Tue, 28 Apr 2015 22:27:43 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EDC3FB926; Tue, 28 Apr 2015 18:27:41 -0400 (EDT) From: John Baldwin To: Adrian Chadd Cc: Warner Losh , Konstantin Belousov , Jason Harmening , Svatopluk Kraus , freebsd-arch Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Date: Tue, 28 Apr 2015 18:27:34 -0400 Message-ID: <1761247.Bq816CMB8v@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Apr 2015 18:27:42 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 22:27:44 -0000 On Tuesday, April 28, 2015 12:10:43 PM Adrian Chadd wrote: > On 28 April 2015 at 09:19, Warner Losh wrote: > > > >> On Apr 28, 2015, at 7:40 AM, John Baldwin wrote:= > >> > >>> I believe UIO_USERSPACE is almost unused, it might be there for s= ome > >>> obscure (and buggy) driver. > >> > >> I believe it was added (and only ever used) in crypto drivers, and= that they > >> all did bus_dma operations in the context of the thread that passe= d in the > >> uio. I definitely think it is fragile and should be replaced with= something > >> more reliable. > > > > Fusion I/O=E2=80=99s SDK used this trick to allow mapping of usersp= ace buffers down > > into the block layer after doing the requisite locking / pinning / = etc of the buffers > > into memory. That=E2=80=99s if memory serves correctly (the SDK did= these things, I can=E2=80=99t > > easily check on that detail since I=E2=80=99m no longer at FIO). >=20 > This is a long-standing trick. physio() does it too, > aio_read/aio_write does it for direct block accesses. Now that pbufs > aren't involved anymore, it should scale rather well. >=20 > So I'd like to see more of it in the kernel and disk/net APIs and dri= vers. aio_read/write jump through gross hacks to create dedicated kthreads th= at "borrow" the address space of the requester. The fact is that we want = to make unmapped I/O work in the general case and the same solutions for temporary mappings for that can be reused to temporarily map the wired pages backing a user request when needed. Reusing user mappings direct= ly in the kernel isn't really the way forward. --=20 John Baldwin