Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page

[Nadav Amit]

> On Jan 21, 2022, at 1:01 AM, David Hildenbrand <david@xxxxxxxxxx> wrote:
> 
>>> 
>>> I did hack something similar and it solved the problem, but I felt it is
>>> a hack. If the thread is scheduled on another core, or if the write fault
>>> is triggered by another thread it wouldn’t work.
>> 
>> Yes, it will not match easily. One question would be how often it would
>> help in practice and if it would be worth the price.
>> 
> 
> 
> I did some more testing and I have to admit that your reproducer is
> really good at finding corner cases.
> 
> Assume we try to handle LRU as discussed ... what I get is a delta
> during the test: ./forceswap 2 100000 1
> 
> 
> anon_wp_reuse 920
> -> we were able to reuse
> anon_wp_copy_count 0
> -> we failed the final page_count() == 1 check
> anon_wp_copy_count_early 634
> -> we failed the early page_count() check considering swapcache and lru
> anon_wp_copy_lock 1
> -> we failed trylock
> anon_wp_copy_lru 19
> -> we failed to clear the lru cache reference
> anon_wp_copy_writeback 99974
> -> we failed to clear the swapcache reference due to concurrent
>   writeback
> anon_wp_copy_swapcache 0
> -> we failed to clear the swapcache reference for other reasons
> 
> So, yeah, we mostly always hit writeback in forceswap.c.
> reuse_swap_page() would have been able to reuse the page if the swap
> backend would have supported concurrent writes during writeback (IIUC,
> zswap doesn't).
> 
> But I think triggering that case that often really is an oddity about
> the test case.

I am glad you find it useful (not my greatest piece of work).

IIRC, I encountered the scenario you describe. It happens when you use
a device driver that uses async operations (most of them). If you use
pmem, it does not happen.

This behavior is not intentional, anyhow.