Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <03b0ed0c-51af-1e68-350c-19a3b38a6e48@redhat.com>
Date:   Fri, 21 Jan 2022 10:01:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.0
Content-Language: en-US
From:   David Hildenbrand <david@redhat.com>
To:     Nadav Amit <nadav.amit@gmail.com>
Cc:     Matthew Wilcox <willy@infradead.org>,
        "zhangliang (AG)" <zhangliang5@huawei.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        wangzhigang17@huawei.com,
        Linus Torvalds <torvalds@linux-foundation.org>
References: <a93988da-80fb-dd32-4717-a6a0bae9e4ee@huawei.com>
 <dc415c4a-63aa-19b0-0fbc-795989970f6d@redhat.com>
 <fb02087a-b102-c91e-ab65-fb02cc8ee0a2@huawei.com>
 <9cd7eee2-91fd-ddb8-e47d-e8585e5baa05@redhat.com>
 <b6df4f7f-c080-ad6c-d1ad-098115f016f3@huawei.com>
 <747ff31c-6c9e-df6c-f14d-c43aa1c77b4a@redhat.com>
 <C8734D0B-B855-4323-A7DF-2D96245951B2@gmail.com>
 <8931808d-db61-0f06-ceb3-f48a83b1f74c@redhat.com>
 <6225EAFF-B323-4DC5-AC4C-885B29ED7261@gmail.com>
 <9071d5a8-ed2d-5cf5-5526-43fe7dd377ec@redhat.com>
 <YenA7Xzd2G2OYvqz@casper.infradead.org>
 <da2846a1-f950-d330-7ada-ad3c9abfde74@redhat.com>
 <42a9b72d-093e-c35c-f4b5-b321a666e67d@redhat.com>
 <288FB900-A688-4EDB-95C6-E63B6E0A15D1@gmail.com>
 <7a18f74f-9dc2-f23d-4f1c-c7a9217f8317@redhat.com>
Organization: Red Hat
Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page
In-Reply-To: <7a18f74f-9dc2-f23d-4f1c-c7a9217f8317@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

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