Date: Sun, 26 Apr 2015 13:04:00 -0500 From: Jason Harmening <jason.harmening@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: 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: <553D2890.4020107@gmail.com> In-Reply-To: <20150425201410.GP2390@kib.kiev.ua> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <CAM=8qan-4SbKJaddrfkv=HG3n%2BHaOPDL5MEPS9DoaTvnhrJPZQ@mail.gmail.com> <20150425094152.GE2390@kib.kiev.ua> <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> <553BC9D1.1070502@gmail.com> <20150425172833.GM2390@kib.kiev.ua> <553BD501.4010109@gmail.com> <20150425181846.GN2390@kib.kiev.ua> <553BE12B.4000105@gmail.com> <20150425201410.GP2390@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--eCCgoIbMufOXxfvxMFPjB42fodthGCmE7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 04/25/15 15:14, Konstantin Belousov wrote:
> On Sat, Apr 25, 2015 at 01:47:07PM -0500, Jason Harmening wrote:
>> On 04/25/15 13:18, Konstantin Belousov wrote:
>>> On Sat, Apr 25, 2015 at 12:55:13PM -0500, Jason Harmening wrote:
>>>> Ah, that looks much better. A few things though:
>>>> 1) _bus_dmamap_load_ma (note the underscore) is still part of the MI=
/MD
>>>> interface, which we tell drivers not to use. It looks like it's
>>>> implemented for every arch though. Should there be a public and
>>>> documented bus_dmamap_load_ma ?
>>> Might be yes. But at least one consumer of the KPI must appear befor=
e
>>> the facility is introduced.
>> Could some of the GART/GTT code consume that?
> Do you mean, by GEM/GTT code ? Indeed, this is interesting and probabl=
y
> workable suggestion. I thought that I would need to provide a special
> interface from DMAR for the GEM, but your proposal seems to fit. Still=
,
> an issue is that the Linux code is structured significantly different,
> and this code, although isolated, is significant divergent from the
> upstream.
Yes, GEM/GTT. I know it would be useful for i915, maybe other drm2
drivers too.
>
>>>> 3) Using bus_dmamap_load_ma would mean always using physcopy for bou=
nce
>>>> buffers...seems like the sfbufs would slow things down ?
>>> For amd64, sfbufs are nop, due to the direct map. But, I doubt that
>>> we can combine bounce buffers and performance in the single sentence.=
>> In fact the amd64 implementation of uiomove_fromphys doesn't use sfbuf=
s
>> at all thanks to the direct map. sparc64 seems to avoid sfbufs as muc=
h
>> as possible too. I don't know what arm64/aarch64 will be able to use.=
=20
>> Those seem like the platforms where bounce buffering would be the most=
>> likely, along with i386 + PAE. They might still be used on 32-bit
>> platforms for alignment or devices with < 32-bit address width, but th=
en
>> those are likely to be old and slow anyway.
>>
>> I'm still a bit worried about the slowness of waiting for an sfbuf if
>> one is needed, but in practice that might not be a big issue.
>>
I noticed the following in vm_map_delete, which is called by sys_munmap:
=20
2956 * Wait for wiring or unwiring of an entry to compl=
ete.
2957 * Also wait for any system wirings to disappear on=
2958 * user maps.
2959 */
2960 if ((entry->eflags & MAP_ENTRY_IN_TRANSITION) !=3D =
0 ||
2961 (vm_map_pmap(map) !=3D kernel_pmap &&
2962 vm_map_entry_system_wired_count(entry) !=3D 0))=
{
=2E..
2970 (void) vm_map_unlock_and_wait(map, 0);
It looks like munmap does wait on wired pages (well, system-wired pages, =
not mlock'ed pages).
The system-wire count on the PTE will be non-zero if vslock/vm_map_wire(.=
=2E.VM_MAP_WIRE_SYSTEM...) was called on it.
Does that mean UIO_USERSPACE dmamaps are actually safe from getting the U=
VA taken out from under them?
Obviously it doesn't make bcopy safe to do in the wrong process context, =
but that seems easily fixable.
--eCCgoIbMufOXxfvxMFPjB42fodthGCmE7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQF8BAEBCgBmBQJVPSiQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwAAoJELufi/mShB0ba7gIAIcGtzGRq1R1W/S8AoR2qTCi
JY9p/fLrD4i1kmiOmcI2hnfBa9UbFLmUGOJnlnrNifQfhY3vnw/IPHhO6zlQW8Jp
llSh6eBiq2lb59+ptA0VLDE33mOzIL2/ZYBVm7EmavGirKVEBtbGLLtCw20ZwiQz
HiRj1cXoppwYyt6xrl1OtbQs9jZNqURvdIwVa2NkwVKZftwqtGv4a5UXJXNr08U3
wbi9niaylcAjwpBlxheemBkC1V0m5QtVvAOSbxMsKwlxOGgMJztnQrksJOWgVvIH
qm4FZeKGOUSSzswfd8l0WWMzkBi4mYdFo6JhRpP3lWYmWow+uBTe0+Y9RU3RxBw=
=nb6L
-----END PGP SIGNATURE-----
--eCCgoIbMufOXxfvxMFPjB42fodthGCmE7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?553D2890.4020107>