Messages in this thread | | | Date | Wed, 8 Mar 2023 16:57:55 +0100 | From | David Hildenbrand <> | Subject | Re: [PATCH v3 1/2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED |
| |
>> >>> 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
| |