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 DC402CD1292 for ; Mon, 8 Apr 2024 07:20:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 597F46B0089; Mon, 8 Apr 2024 03:20:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 547E16B008C; Mon, 8 Apr 2024 03:20:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4371A6B0092; Mon, 8 Apr 2024 03:20:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 258F76B0089 for ; Mon, 8 Apr 2024 03:20:13 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D2D6CC07C8 for ; Mon, 8 Apr 2024 07:20:12 +0000 (UTC) X-FDA: 81985515864.16.11C84E6 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by imf09.hostedemail.com (Postfix) with ESMTP id 64EF7140002 for ; Mon, 8 Apr 2024 07:20:09 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NpFRbrOb; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.11 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712560810; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4RQtr7ub6MY3J2UEq4n6hWUcmoKNuqjvRBOteqI59Nw=; b=O9vXlKF+L6+RF4fiA2OXXhfCcGNjEWmBDtBDQKzWVQe53she9CfNqmvnfQ1ErOTg4qUsHU m3WsgrTxuRvjx6cVEJcM1HCQkfawtSmBhNE5vwrABUwQopyIVV5KP2c7YrbUAE2wUzTj1E 19xqh44XOpKZfgKKtgZTOeIOQw660wI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712560810; a=rsa-sha256; cv=none; b=0TStILGXPGLQRC0yozaBjUglPeLFv9KOCJMfpLRqbJXFfmxumoxuP+5rPyyH9wuf2O1OXP VFcW8Kqn4sP7o2j0XwUdZ9jMzoQbILcFi81+YpkBx2R52U3dXw5dRWqGBfwYEC8Wtd8yE0 j8qBp34ElgwBXxE+lsAcjVLVAtq9KP0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NpFRbrOb; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.11 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712560810; x=1744096810; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=mpDLGOwCL1tUD/2WOABKB5CAMRKkqSqR984nsxK/Eio=; b=NpFRbrObHDTWJUunoG4o/ycAswehv+pfAWZr/Mo9y9ik3KxajjNPcWZW YwBR8r7fpPCIc8Y6l4X0IHZ3UP7IrHYzLojkIBw1vesxrUlDo7TK8qk96 58XccgmNcpVrYvWGWJko54B1Y/8IuK1jA3tbOdJRQUXAsPts6wPsaur98 QlA9CNzkmklqgWSgwO9XzZc4VVPNWfFAGJQvi1Tr8QjtrT4OvuH8FSyql wHgEhcPp1EgleGw01QqSrdUvL7qEMwqRGafMiprUrAUMU1VCTUFaELyhd 4IDfE+WB94akc3DjQJbPg4z52/4hk/6yQe0KrIlLkJB/ZcKsxG8EjKoXL Q==; X-CSE-ConnectionGUID: gtULz3LqRiKWZ1ivYDyapg== X-CSE-MsgGUID: 795gBRSFR9yEG1qF9tHKmg== X-IronPort-AV: E=McAfee;i="6600,9927,11037"; a="18395453" X-IronPort-AV: E=Sophos;i="6.07,186,1708416000"; d="scan'208";a="18395453" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2024 00:20:08 -0700 X-CSE-ConnectionGUID: 1IcUa/W+Rwm0hbUwjPz4QQ== X-CSE-MsgGUID: Ht638xVlQ+exfOkQsEYzXQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,186,1708416000"; d="scan'208";a="24270688" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2024 00:20:03 -0700 From: "Huang, Ying" To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, david@redhat.com, willy@infradead.org, ryan.roberts@arm.com, yosryahmed@google.com, hughd@google.com, hannes@cmpxchg.org, surenb@google.com, xiang@kernel.org, yuzhao@google.com, chrisl@kernel.org, kasong@tencent.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, hanchuanhua@oppo.com, Barry Song Subject: Re: [PATCH 4/4] mm: swap: entirely map large folios found in swapcache In-Reply-To: <20240402073237.240995-5-21cnbao@gmail.com> (Barry Song's message of "Tue, 2 Apr 2024 20:32:37 +1300") References: <20240402073237.240995-1-21cnbao@gmail.com> <20240402073237.240995-5-21cnbao@gmail.com> Date: Mon, 08 Apr 2024 15:18:11 +0800 Message-ID: <87wmp88gr0.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: z8bfh6i1w3h6htponyuu386fkn41i8rp X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 64EF7140002 X-Rspam-User: X-HE-Tag: 1712560809-678717 X-HE-Meta: U2FsdGVkX1+Ix2cNAdo1NZSrKaqkKQYwUg2+2RQRvuQmRLMvry57a3iKn6AiqINLIXvcnf8FIxk+Z4kXxv/z02TCQvnJVsnaGSt28oMX41rqCy41dP5ucAU9coeZ+hDuqzHr9dVU9xtIWR0eE45PNo71ov75dQ85DcqxbQuBtDJIUqlyPM95RKdxzBaW0UQmhGZ+lLlRrvwF+ZDZq0du9qQxf+6nVZ9x70aHr6OXmYBBfNpG9575cENywYyyZTO/eO3VrRGJnmOwjLU096K163AAK/xae4mVRl8SUKIlwqSwNsxLd1xx83T/shMh1w8hV/Wx4F6PtBF/joGz9wYj0zBKWJvGFZ79h/93KVwWcJIhMBdsJYTm2ilfDMv76uNvO+yc5G0GiOJt642NL1Z32fLSPvAFUhndI+F4evySBZbwloEkytCI+hjVcwFbaFaiUtmNN1IGe5mo0c5B2MyBJuUMnUfoLIu17ATvUrDj9sgyG4Ll6oKuCI2/PYNwVuwhfzbDMfGvga8tdCOMcmbIFyL/VjiritvIEwkJjLeQDEkN6sLD41P9rgRUODZyl0rAL6Qbn/utM4QKVjry5OFUxCBWBASPpNZGAZM8RXg62FMEJCbW/hTNwJwMUGXVGtqQ7fJhHEMEZTtnB9YDo7Lflozzpim7Z4fWJA7MbY7l954ZS9OKoH0gDLkWhFKioLHJ3QLwFXuBGqf4iVksnhAht+w3JJG9z8KxmCz7Q9c09aep7h3uyroIp0LPv3fo1+B+mrYMfqMaLfWeWXyZfLoPrO3kDGBophm203MdXZFD+1avLNBnEeBh0Q/WReB52mwt/zGq5wEPABBKqP6r1dIkdOcEivSgOADBLo2lygU30zrFxbSQVnQMD3814KfAU6kxnNYkrKdxfpmJAxea3moNSz2o27SBzYZvT9I8/mpKJdWeAc40a1fmlt+gj2bJnHgFgZTRVZlIGYA+3O5XYZ+ 82V1x+o4 TRSxacdQTpqvKl2vZZYCnvtF4oBiHkNRNP/IBq6O2wAzh+Z7dQ5sd99FaJ1iEP3Qb064bVmALfWvVBZZZnNoCjTFaGrmoVhPcoeVb/aK2dV6Ts4BDUn2qAlUYRw6r8uin3cA27X1R6NPLPaNN9k7u/mgsiJ48OBywdVb9sUK4CJHBK0+SWGbFO4ss1PBPB8SQr3cVmOB0/I79isE6p8Z8daN4gHNFl0HGk7/OGl5t149O26aQIOPCsneDyQiZP4afJeXk 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: List-Subscribe: List-Unsubscribe: Barry Song <21cnbao@gmail.com> writes: > From: Chuanhua Han > > When a large folio is found in the swapcache, the current implementation > requires calling do_swap_page() nr_pages times, resulting in nr_pages > page faults. This patch opts to map the entire large folio at once to > minimize page faults. Additionally, redundant checks and early exits > for ARM64 MTE restoring are removed. For large folios in reclaiming, it makes sense to restore all PTE mappings to the large folio to reduce the number of page faults. But for large folios swapped in, I think that it's better to map one PTE which triggers the page fault only. Because this makes us get the opportunity to trap the page accesses to the sub-pages of the large folio that is swapped in ahead (kind of swap readahead). Then we can decide the order of large folio swapin based on the readahead window information. That is, we may need to check PageReadahead() to decide whether to map all PTEs in the future. -- Best Regards, Huang, Ying