lkml.org 
[lkml]   [2023]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2023-03-27 00:50    [W:0.064 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site