> 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.
