From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D208C433F5 for ; Fri, 21 Jan 2022 17:43:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7622A6B0080; Fri, 21 Jan 2022 12:43:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 710C46B0083; Fri, 21 Jan 2022 12:43:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D8976B0085; Fri, 21 Jan 2022 12:43:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0116.hostedemail.com [216.40.44.116]) by kanga.kvack.org (Postfix) with ESMTP id 4E25A6B0080 for ; Fri, 21 Jan 2022 12:43:58 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id F3A9C94FBF for ; Fri, 21 Jan 2022 17:43:57 +0000 (UTC) X-FDA: 79055017314.30.38C0324 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf25.hostedemail.com (Postfix) with ESMTP id AFDF8A000E for ; Fri, 21 Jan 2022 17:43:57 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id t18so9173459plg.9 for ; Fri, 21 Jan 2022 09:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5yBj3WKsDqrKvhosut7Au96eMd8ifdmMwiAx6WznJJg=; b=MSfbGULULNWFoZz9zq8jbfTsWmcNlHiBq5Bc91hYYPr/DnYNj3TaEvIeRKo36wbzGO O74mJZMpnhLyohm66AKQF6IPcIsTtZFHCmkmtV7nqp7kpWbtZRHBOalXltHKn4MhLB6y TfWODrdzwd5VVKBlUBB4RkQ8XjD/3OUqnQr6cIdGgOEPyk7O9CTG/x3j77ZxlqIDdNxH WNgjEVbbFztybma6V3PFrTC/h+jKqzPfFQCgkPkgIeYC8yTdVoo+kT9DrggXwESdKGC6 qrWg0c5RURFDcDqzj3YW1r/mlNEFF3fSRIWahbI6fnVWLK66Mrc84YCeQw4Yw9pWxTZz 6F9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5yBj3WKsDqrKvhosut7Au96eMd8ifdmMwiAx6WznJJg=; b=cE2EZk9erso0NigaRS/xhyo4vjWKhO3bQl6tdkeZVgh02blpH1yYe747KpR4zYAL51 NqNRQYt4Mfes3wUygy+kHxcejTo8gXo7E6VLuUvBY/AjR2/ussqTKi5ng2noK7SLnoK6 oOZBUVIrn4815nlizgrFoevh97IP4FB8iqnJLbIewGxNLo275f2X7O5qUYz9vZ1H8sRb RnSeHjoEI6QpNLS3ULIsp7p8aky4CfCGw7eJqOle02eI95kPdN5OH4LgexVDDhhsl/g1 5SKDcT2PLJbTTliOZobCJe4ysGlldfNtOdZCLf/NXW8Y8nOxUScOTqtREiuKttDcwW2/ BUkw== X-Gm-Message-State: AOAM5327z9WMmZm1HSy57fYuD01S3q91y4NdcDOpLDA+6QUgx9gRPXzh 3CRPOHOolEQBBOGx0t0xsHY= X-Google-Smtp-Source: ABdhPJyBGtAYRb3J3bCVGT7+zDw56OdBPKGmybQTfiuUh57u9/gsTdmlL70vhudKKUFWdh+Sze8Qhg== X-Received: by 2002:a17:902:ea0b:b0:14a:f5ba:1e5e with SMTP id s11-20020a170902ea0b00b0014af5ba1e5emr4823317plg.125.1642787036351; Fri, 21 Jan 2022 09:43:56 -0800 (PST) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id y21sm7652058pfi.78.2022.01.21.09.43.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jan 2022 09:43:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page From: Nadav Amit In-Reply-To: <03b0ed0c-51af-1e68-350c-19a3b38a6e48@redhat.com> Date: Fri, 21 Jan 2022 09:43:54 -0800 Cc: Matthew Wilcox , "zhangliang (AG)" , Andrew Morton , Linux-MM , Linux Kernel Mailing List , wangzhigang17@huawei.com, Linus Torvalds Content-Transfer-Encoding: quoted-printable Message-Id: References: <9cd7eee2-91fd-ddb8-e47d-e8585e5baa05@redhat.com> <747ff31c-6c9e-df6c-f14d-c43aa1c77b4a@redhat.com> <8931808d-db61-0f06-ceb3-f48a83b1f74c@redhat.com> <6225EAFF-B323-4DC5-AC4C-885B29ED7261@gmail.com> <9071d5a8-ed2d-5cf5-5526-43fe7dd377ec@redhat.com> <42a9b72d-093e-c35c-f4b5-b321a666e67d@redhat.com> <288FB900-A688-4EDB-95C6-E63B6E0A15D1@gmail.com> <7a18f74f-9dc2-f23d-4f1c-c7a9217f8317@redhat.com> <03b0ed0c-51af-1e68-350c-19a3b38a6e48@redhat.com> To: David Hildenbrand X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: AFDF8A000E X-Stat-Signature: 6qmp7ei3yhadwowb6nbopa5dup9byqn9 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=MSfbGULU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-HE-Tag: 1642787037-668267 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Jan 21, 2022, at 1:01 AM, David Hildenbrand = wrote: >=20 >>>=20 >>> 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=E2=80=99t work. >>=20 >> 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. >>=20 >=20 >=20 > I did some more testing and I have to admit that your reproducer is > really good at finding corner cases. >=20 > Assume we try to handle LRU as discussed ... what I get is a delta > during the test: ./forceswap 2 100000 1 >=20 >=20 > anon_wp_reuse 920 > -> we were able to reuse > anon_wp_copy_count 0 > -> we failed the final page_count() =3D=3D 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 >=20 > 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). >=20 > 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.