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 E58A0CD1292 for ; Mon, 8 Apr 2024 07:51:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 734E76B0096; Mon, 8 Apr 2024 03:51:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BD976B0099; Mon, 8 Apr 2024 03:51:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 537706B009A; Mon, 8 Apr 2024 03:51:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 338EC6B0096 for ; Mon, 8 Apr 2024 03:51:03 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DFB411C05CA for ; Mon, 8 Apr 2024 07:51:02 +0000 (UTC) X-FDA: 81985593564.06.61A674C Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by imf28.hostedemail.com (Postfix) with ESMTP id 9565FC000C for ; Mon, 8 Apr 2024 07:50:59 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=CIlQs3PW; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.8 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712562660; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8JXl7Yy2dWnkekQcrQhGZOd4yqDNpzYeXTzyaXHxX9I=; b=XK4EQvJBMLyLtH1QLqORvsIcN398q9HVTVDFA0aQ5c4Yn4LFQWz2O120S+9bZTl7DYCdzU LfVbXmcSqY1f5g1G9bIgGrHGrZ6qz8fRVFPtsZtveIalyhaG5H+OkCK5BzRwYjzV8Oyyqr gMf6h6LUnjeEH3psMSGlzKh6Mu3raDk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=CIlQs3PW; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.8 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712562660; a=rsa-sha256; cv=none; b=B2dTV5x5RDnNtpQ10BstfGm+NS1bbVsO3j2BTAwlBTU0waKshTMRtBp9Q8Ya7rg00bg+Ph oFyNEVV9Gmqrjyn55J/jqip2kn9Lyaj/1y/UU5osnp74VXxCXDW9ZVNGOwUG8G8cfbPn/o 4QU7ERkz7BckzKcNU/QGj2c6m5XcOW4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712562660; x=1744098660; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=b8cq4Ftgg1UhiIhc5pu98jmFABlMqvquaAeYO0bWdqs=; b=CIlQs3PW2NQLiKVegsB5xb7oXYnQ6G6+PNvLd0Q383bIqSLxj6XNw9El ccsCmdTOw7iMnMSOB+ECyU+HAJJ5wOtazienqEehOrjJgHSfdWNd5h9eO IRHdhjOeooOrH/3u8PJRULqVkr8xE8p4kR4SbPlyFA0xAiKPWKulTFGKs OJHJn5pcHmk5FgbH99HPBGGG0GMfNyl6hgp36ET1XvSwrwnIDMnXEtrUG e2e0p4FWWkGPVcMfEs2FJRc30nv0SnBf2ogMD4UDMkiEhD7YMJg9kswAo K3vZ98KfZDCuuHVj4pwRFVf+gOifygYkQkPz0/gmNqawovllvMjECGWei A==; X-CSE-ConnectionGUID: YxgW4YRxSGuYVQ/wk+7IUg== X-CSE-MsgGUID: Nq71GczrRvydxb2rZVdRcw== X-IronPort-AV: E=McAfee;i="6600,9927,11037"; a="25325207" X-IronPort-AV: E=Sophos;i="6.07,186,1708416000"; d="scan'208";a="25325207" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2024 00:50:58 -0700 X-CSE-ConnectionGUID: +cIMU4iZT/GhP19W2xKeJQ== X-CSE-MsgGUID: y2o037AtTeqiWgCkkVsMaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,186,1708416000"; d="scan'208";a="57261771" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2024 00:50:54 -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: (Barry Song's message of "Mon, 8 Apr 2024 19:27:52 +1200") References: <20240402073237.240995-1-21cnbao@gmail.com> <20240402073237.240995-5-21cnbao@gmail.com> <87wmp88gr0.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 08 Apr 2024 15:49:00 +0800 Message-ID: <87plv08fbn.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9565FC000C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: boe4xmtifykm44mfc5quykrgxj5j1itb X-HE-Tag: 1712562659-949578 X-HE-Meta: U2FsdGVkX19/bhoFJ9jz01b0rZoO9SfH2E4pqczVaC2d1oOJJkTyHRQZLc9joXfd8qfmzcTDTMq8CurszmzRmCFUWDIZKh7vgUlmT5jvzJ25epQXXR+pT0Mg/Mzqi9FWiu7algfWq3f4TFv6qBKHUj3oN/gHQfSeH5CikJbJRRFf+p8u3klaqynk0R7poukJvDRFyOeZdaOEA/pcgieNXjh2b5CvOp0U5KkQnr86vnOFn8lqo9DvT+jreP14IGiWBN9PUrtXJgvCLikkX2w6H8ZZot3KsBsbCPWSUHoJ3a+0765EYeEnJ0rz0QS5aGVtZ9LtNmwvi6b5LyoZ/evmMPkVSSew/NEKUA/DN+xgSu9GzMhWgwOGxbUSASsiJSloUPWd8xonc1mJj2oGHR/3OnkzINCiFh9TaYT6ZiN8q6SKzZkgYlJn5QKGAVi74wIstFK419kbUQWKp5I9xp31UHWtFYn/HYPl22yRqllYDp6pjtTPgWtV+wxAbv1qew8bKeRxbdM9Ed7fIMKKzTDtoRoRboTaXdwkeSCq3rhV8TWNLF4y5iYT6DL8nbmDJWHRU8U/kt6fNnabePQIUBFghfRNFbdgTC8OVdquktw6TQ1kJaZEeDOnkEEg/L2ELF9mC+zMHS+ecmznOt/DL2v8l3mfjmy3xMtU1Oyt559NrjC5x1YkAqgMPhKkuws3THFkYJ495AeDrcJ5DtwvLdGp94z0/aIOTM+He5hUKumKxu6fYBgffQYSd11a/WGNfUJ+6EwVLYNspp4s7pAdz7tcaMcax974YeT+4kOUlmnjyRwRhIWgN046igczHT+hfgBX6swWVLycGBTTG9zA17ED9IXDGBT///YtPhCh7lKgkwa4ZqaHkS6mizzUfAt3lxRp7fYBTD7NEy/B+aQGxNhMvESroozV2vXV6lHr35m/WU3gGUc54DV4HhIVki9xe0RwZyGvZqnkFQrzicgYSdi liNP8WF7 zSDGNJNRWS2FiNiA38hQ7YiFluV+mbXRgnXvi8pldua/OX+4OoM/5yvXhPHcQ8IBupaei78fJvMPZmV3lweIoi+lPHOIVA2Qxe2cubm5TWrKyQk93b4a6lMz20beGYzjJWUnn63wroz/HtQCaw2ULLJkB0xnKXd2RjmvAiD13zkRweRm0xlSftMBqxOnxZDUADeS9+nZmy+HhruxBUTEtgWNcNhD/1OnZzzsPNF9hxEIrOjZmJpFgl//m2g/6Pq57/+20xfDslnON34o26Xx8GfvREQ== 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: > On Mon, Apr 8, 2024 at 7:20=E2=80=AFPM Huang, Ying = wrote: >> >> Barry Song <21cnbao@gmail.com> writes: >> >> > From: Chuanhua Han >> > >> > When a large folio is found in the swapcache, the current implementati= on >> > 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. >> > > Indeed, this patch addresses the refault case first, much less controvers= ial > then :-) > >> 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. > > Another scenario occurs when a process opts to utilize large folios for > swap_readahead. Subsequently, another process encounters the large > folios introduced by the former process. In this case, would it be optimal > to fully map them just like the refault case? We only need to trap the first access to the readahead sub-page. So, we can map PTE for all sub-pages without PageReadahead(). IIUC, now readahead flag is per-folio, we may need to change it to per-sub-page when needed. -- Best Regards, Huang, Ying