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 3536FC433F5 for ; Mon, 30 May 2022 23:04:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E0FF6B0071; Mon, 30 May 2022 19:04:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 990076B0073; Mon, 30 May 2022 19:04:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87C376B0074; Mon, 30 May 2022 19:04:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 76B8D6B0071 for ; Mon, 30 May 2022 19:04:12 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 4C66A80858 for ; Mon, 30 May 2022 23:04:12 +0000 (UTC) X-FDA: 79523939544.11.ACF1B96 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 5F3AB140055 for ; Mon, 30 May 2022 23:03:57 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0608B60FC0; Mon, 30 May 2022 23:04:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44D62C385B8; Mon, 30 May 2022 23:04:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1653951850; bh=+UGtoxPlhwYJZG/Fb3M4NWWp3KEr2u92gtuPNKvQGl4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Bt8rnnr6VZikWr5d22PbZF60kJdfCrOWQl0RM3ZT9nEc+trY7uhQg00fLbzQVE+bl OcaN/qqZbqbcsXH7mV6RlqM2N1FeWIhuuYj05y87u7H/U9BlUZ3khR9lNoYd+cyyXx Kn0siaiFjV1zQ8uZbGWj2ZgBBwxA+2tsJr3EyNoA= Date: Mon, 30 May 2022 16:04:09 -0700 From: Andrew Morton To: Miaohe Lin Cc: , Subject: Re: [PATCH 2/3] mm/swapfile: avoid confusing swap cache statistics Message-Id: <20220530160409.c9b17085adb6112d8580f37d@linux-foundation.org> In-Reply-To: <20220527092626.31883-3-linmiaohe@huawei.com> References: <20220527092626.31883-1-linmiaohe@huawei.com> <20220527092626.31883-3-linmiaohe@huawei.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5F3AB140055 X-Rspam-User: X-Stat-Signature: 371yjfm96cae3ooutamdzyb7m9c95sow Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Bt8rnnr6; dmarc=none; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1653951837-559915 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 Fri, 27 May 2022 17:26:25 +0800 Miaohe Lin wrote: > At swapoff time, we're going to swap in the pages continuously. So calling > lookup_swap_cache would confuse statistics. We should use find_get_page > directly here. Why is the existing behaviour wrong? swapoff() has to swap stuff in to be able to release the swap device. Why do you believe that this swapin activity should not be accounted?