On Jun 28, 2022, at 1:56 PM, Peter Xu <peterx@xxxxxxxxxx> wrote:
> On Tue, Jun 28, 2022 at 08:30:46PM +0000, Nadav Amit wrote:
>>> On Jun 28, 2022, at 12:15 PM, Peter Xu <peterx@xxxxxxxxxx> wrote:
>>>
>>> ⚠ External Email
>>>
>>> On Mon, Jun 27, 2022 at 11:37:32PM +0000, Nadav Amit wrote:
>>>> Besides the benefit of avoiding a TLB flush, there is also the benefit
>>>> of having more precise dirty tracking. You assume UFFDIO_CONTINUE will be
>>>> preceded by memory write to the shared memory, but that does not have to
>>>> be the case. Similarly, if in the future userfaultfd would also support
>>>> memory-backed private mappings, that does not have to be the case either.
>>>
>>> Could I ask what's the not supported private mapping you're talking about
>>> (and I think you meant "file-backed")? I thought all kinds of private
>>> mappings are supported on all modes already?
>>
>> Yes, I meant file-backed. See vma_can_userfault() for the supported
>> types of memory:
>>
>> static inline bool vma_can_userfault(struct vm_area_struct *vma,
>> unsigned long vm_flags)
>> {
>> if (vm_flags & VM_UFFD_MINOR)
>> return is_vm_hugetlb_page(vma) || vma_is_shmem(vma);
>>
>> #ifndef CONFIG_PTE_MARKER_UFFD_WP
>> /*
>> * If user requested uffd-wp but not enabled pte markers for
>> * uffd-wp, then shmem & hugetlbfs are not supported but only
>> * anonymous.
>> */
>> if ((vm_flags & VM_UFFD_WP) && !vma_is_anonymous(vma))
>> return false;
>> #endif
>> return vma_is_anonymous(vma) || is_vm_hugetlb_page(vma) ||
>> vma_is_shmem(vma);
>> }
>
> I'm confused. Let me ask in another way: do you mean !VM_SHARED when you
> say "private"?
>
> Both shmem & hugetlb support private mappings for all three modes, afaict.
Sorry, let me more clear. I meant private (!VM_SHARED) file-backed memory.
>
>>> Well I never thought anyone would be using soft-dirty with uffd because
>>> logically uffd-wp was somehow trying to replace it with a better interface,
>>> hopefully.
>>
>> I have heard about some who does (not me). So I do not make it up,
>> unfortunately.
>
> If in any form you can get the reason of using soft-dirty in that use case
> please kindly share more. I think it could be that uffd-wp is not working
> as good as soft-dirty in some way but we can think about it when there's a
> valid use case, so ultimately it's more possible for a full replacement.
>
> Sync messages can be a problem and they're indeed slow, soft-dirty is by
> nature async. But still I'd like to check in case you know.
It’s not my thing (not VMware’s either), so I do not feel free of sharing,
but anyhow I know very little. I think that project started before uffd-wp
was implemented and that’s the reason they use this strange combination. It
should not be our main motivation - just to say that users are “creative”.
Again, I will get back to you with the rest.
