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