>> >> 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. -- Thanks, David / dhildenb
