Re: [PATCH v3 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED

[David Hildenbrand]

> > > With WP_UNPOPUATED, application like QEMU can avoid pre-read faults all the
> > > memory before wr-protect during taking a live snapshot.  Quotting from
> > > Muhammad's test result here [3] based on a simple program [4]:
> > >
> > >     (1) With huge page disabled
> > >     echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
> > >     ./uffd_wp_perf
> > >     Test DEFAULT: 4
> > >     Test PRE-READ: 1111453 (pre-fault 1101011)
> > >     Test MADVISE: 278276 (pre-fault 266378)
> > >     Test WP-UNPOPULATE: 11712
> > >
> > >     (2) With Huge page enabled
> > >     echo always > /sys/kernel/mm/transparent_hugepage/enabled
> > >     ./uffd_wp_perf
> > >     Test DEFAULT: 4
> > >     Test PRE-READ: 22521 (pre-fault 22348)
> > >     Test MADVISE: 4909 (pre-fault 4743)
> > >     Test WP-UNPOPULATE: 14448
> > >
> > > There'll be a great perf boost for no-thp case, while for thp enabled with
> > > extreme case of all-thp-zero WP_UNPOPULATED can be slower than MADVISE, but
> > > that's low possibility in reality, also the overhead was not reduced but
> > > postponed until a follow up write on any huge zero thp, so potentitially it
> >
> > s/potentitially/potentially/
> >
> > > is faster by making the follow up writes slower.
> >
> > What I realized, interrestingly not only the writes, but also the reads. In
>
> Curious why reading a zeropage would be a problem?

Oh, my thinking was that with markers you postpone placing the shared 
zeropage. So the next read access will require a pagefault to map the 
shared zeropage. Your v1 would have performed best in that case I guess.

--
Thanks,

David / dhildenb