Am 11.03.21 um 14:17 schrieb Daniel Vetter:
[SNIP]
So I did the following quick experiment on vmwgfx, and it turns out that
with it,
fast gup never succeeds. Without the "| PFN_MAP", it typically succeeds
I should probably craft an RFC formalizing this.
Yeah I think that would be good. Maybe even more formalized if we also
switch over to VM_PFNMAP, since afaiui these pte flags here only stop the
fast gup path. And slow gup can still peak through VM_MIXEDMAP. Or
something like that.
Otoh your description of when it only sometimes succeeds would indicate my
understanding of VM_PFNMAP vs VM_MIXEDMAP is wrong here.
My understanding from reading the vmf_insert_mixed() code is that iff
the arch has pte_special(), VM_MIXEDMAP should be harmless. But that's
not consistent with the vm_normal_page() doc. For architectures without
pte_special, VM_PFNMAP must be used, and then we must also block COW
mappings.
If we can get someone can commit to verify that the potential PAT WC
performance issue is gone with PFNMAP, I can put together a series with
that included.
Iirc when I checked there's not much archs without pte_special, so I
guess that's why we luck out. Hopefully.
I still need to read up a bit on what you guys are discussing here, but
it starts to make a picture. Especially my understanding of what
VM_MIXEDMAP means seems to have been slightly of.
I would say just go ahead and provide patches to always use VM_PFNMAP in
TTM and we can test it and see if there are still some issues.
As for existing userspace using COW TTM mappings, I once had a couple of
test cases to verify that it actually worked, in particular together
with huge PMDs and PUDs where breaking COW would imply splitting those,
but I can't think of anything else actually wanting to do that other
than by mistake.
Yeah disallowing MAP_PRIVATE mappings would be another good thing to
lock down. Really doesn't make much sense.
Completely agree. That sounds like something we should try to avoid.
Regards,
Christian.
-Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
