Date: Tue, 28 Apr 2015 18:27:34 -0400 From: John Baldwin <jhb@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.com>, Jason Harmening <jason.harmening@gmail.com>, Svatopluk Kraus <onwahe@gmail.com>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <1761247.Bq816CMB8v@ralph.baldwin.cx> In-Reply-To: <CAJ-VmomqGkEFVauya%2BrmPGcD_-=Z-mmg1RSDf1D2bT_DfwPBGA@mail.gmail.com> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> <CAJ-VmomqGkEFVauya%2BrmPGcD_-=Z-mmg1RSDf1D2bT_DfwPBGA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, April 28, 2015 12:10:43 PM Adrian Chadd wrote: > On 28 April 2015 at 09:19, Warner Losh <imp@bsdimp.com> wrote: > > > >> On Apr 28, 2015, at 7:40 AM, John Baldwin <jhb@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1761247.Bq816CMB8v>