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 96A2ACD128A for ; Wed, 10 Apr 2024 01:48:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25B8F6B0087; Tue, 9 Apr 2024 21:48:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20C376B0088; Tue, 9 Apr 2024 21:48:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FB376B0089; Tue, 9 Apr 2024 21:48:19 -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 DE1CA6B0087 for ; Tue, 9 Apr 2024 21:48:18 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 486251A0589 for ; Wed, 10 Apr 2024 01:48:18 +0000 (UTC) X-FDA: 81991937076.17.0C06A9A Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf26.hostedemail.com (Postfix) with ESMTP id 0A7B0140016 for ; Wed, 10 Apr 2024 01:48:15 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mrKwnY3b; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf26.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.15 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=1712713696; 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=7+UbcOEPNFbKJLRLXxiMyki3vxxTuzc8Cfcx6rhytxs=; b=xVIGGx7HZ51z0tEwLqWJzGmF63rikLnhCXfOOrzksXoL6Y7R08Af38krnXXvR9a/rQH0PV kM8FxVFkUk5SH4M7e/Px1Xj/UlaDduYBv6kLNL8QZa64ogHU8xH9Tw/jpWieqAhlju8t7F pwW8+QxRv2rVKHhAOLLtbGarToo+sOI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mrKwnY3b; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf26.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712713696; a=rsa-sha256; cv=none; b=YklywglR1Enk3B55jm8KxB1oS1rLYzTBpP2zyemFVIzcw3j3uCLfgd0H3z4Iq7+0yCaItP JQ8BDrf2pJ3n09vqgzjJRloHxgjSFffs8tOtvuZF22DcM4F2tCafoi8NDO7VMbZj94SMxv Ozb8WhTT9Z8QUOY/Lif5aA/TVt9d9/g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712713696; x=1744249696; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=NcKvOkrCzR342U93keVujN6cdA/17UZMHK43RsPTVsY=; b=mrKwnY3bA4hS9z2ZjnH9DRaDzgS+jQbkx7kDjf5LP59hBc70QX0Sgwfj 9jAaA4MMMxQJgnmiZ7KzeiDAG3Moh9OclMnj6tJNrIj7ARXBVbh9w9Vkm KjAR++cXTtYmNEJ73oT1M4wCyRlbpTiNx7uOMNgOuvpjL0RAqHlgZCYy6 Kr3i44Edcumdir/mj9Nm+d77cCPsSGvFQmAEqqlAm7aYtp14r4U2EhluD mI0YHmrJ/0wJgn9zc61HvbmzPyaZFjOMMW/ribdPgu3AwXqaHpSsvykaF 5JeDOKCbcb2f+P859ohD34gkLWJjV5d28vkF0WqiPMZUrJOwK2TJQ51lz Q==; X-CSE-ConnectionGUID: YIkpnFRhTeyCHOxAJIUTag== X-CSE-MsgGUID: 4ZyuoPMcQoSjPdZzAMhrmw== X-IronPort-AV: E=McAfee;i="6600,9927,11039"; a="8235329" X-IronPort-AV: E=Sophos;i="6.07,190,1708416000"; d="scan'208";a="8235329" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2024 18:48:15 -0700 X-CSE-ConnectionGUID: M1tPkJiaQKOyDTqRm15LIA== X-CSE-MsgGUID: 2XzmfPgPR7C2Qhk1Wl87ig== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,190,1708416000"; d="scan'208";a="24903108" Received: from unknown (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; 09 Apr 2024 18:48:11 -0700 From: "Huang, Ying" To: Nhat Pham Cc: Zhaoyu Liu , Andrew Morton , ryncsn@gmail.com, songmuchun@bytedance.com, david@redhat.com, chrisl@kernel.org, guo.ziliang@zte.com.cn, yosryahmed@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] mm: swap: prejudgement swap_has_cache to avoid page allocation In-Reply-To: (Nhat Pham's message of "Tue, 9 Apr 2024 10:52:40 -0700") References: <20240408121439.GA252652@bytedance> <20240408132704.f966adc8d3928df4d3b8c0a9@linux-foundation.org> <87edbf8hta.fsf@yhuang6-desk2.ccr.corp.intel.com> <20240409145740.GA543696@bytedance> Date: Wed, 10 Apr 2024 09:46:18 +0800 Message-ID: <8734ru6lcl.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-Rspam-User: X-Stat-Signature: wz1bjfp4ocmsj5omof4akpw4scppdffd X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0A7B0140016 X-HE-Tag: 1712713695-812072 X-HE-Meta: U2FsdGVkX1+AiCDOG2vWM2bLpkMR6Q1XGcaVgBjgKeSX9PJZqO26auiKgm5Mw6g1alSoGS7IMqfX1ta5sLULY8QsbNPRLgEvTL0vDdj+2QpELYR4Gh+nPW5xRWbzaeTpgOozmAd/I0Nx3cAUmO3dpFprcKc9gSykn3fjXpiIIG6zH/2vpSp8xQeDiTA1NybuvxNsPSNMi2XWODd0/YLPGXaWN6bPscU6NN2orRTrSOBZTiDa+TJhslHBCw/svpKOuXdMpxZdADbgCkqysCD8iaDCu3vUqJOk6SaiGBjB0vUJYnbHHpPL9Aaqy2/tXoEyuNOKaCBgQrpWNw0JwhXiptOC7jYQNR2a5rYCYUimLPGLeCvKwtzC5o/HtdCb1cdvmbd2WjJn+rnqbSMar6sxlpAotrsoZaIQZvTx8DTDZKg+C/ln6KHWMG7d7JQnFNWuQ9gTCekI3kcPOFbzzdP+8ujfgnsrtqxYoA8DjYfr2zJfRz7T2bDzrJJpmQRRiT7FsfrTwhJMTc+g3qaeWDrOKZjoqs3Ojw0M8RMHdoGaBPv2ZWiOtkvzZK0Zmne1uzgeKqOMvtcEOjJp4JW0yYgyxEQWZLjZ8sHC9w1WnJNXMB0sWetpc5W+582uVchhux8rL4jatOjyNoYmqhJ7/QfRem9/X+FVFZCztQUKGU89cZyz5Crm9ox5eP0BvhEAlOEb5grvMYea9lUjS1+iXvIRZ5LfnEK2nKidK0FULNr8HSp+birUMIjKL44gAZWhpX+6LgDlRsUulzVAz4J/2j+pNH3AI4Y048Vf7AC1lX7ZGBSaILrfqMudFRdts9XP5Al1lWP/Z4W9zKlgS5dwuMvsZucgkm8wIH7Eq25QXUo1LdZ8JmT83PFTspOkfYFAzE7+ojW8zWBJiwEONeDVOyrFfByRZOV9Mymt1Fa1Lq5ykBQ5UkEiwDV0F57ufi+HyGslE6XY6/7ITCs+OKpSyAz l7KqPoj/ Ri3A7Syg0RkNSchc17Yri1kE0eF7YnTFYXGpONEUS332o/qTo9MSpoZmdA/kcGR2l/7tA/GGAt8Qz9wklabX/f3AY1vrbhy3mzV1Vo4d1fPmqopel3Xyx6QfVc96PVDIFeqGvbkt+4uezuWkHgHZZQpT3jW/pvZCdHBWpVvO6CJzrp+P19kZ4GaHx+98yrEBGZLWtonF751fT2ecbPSUT4yu1wlcUGie2MAvlJG2IBmKe+tw4S5C2ECWwZt4jasoyxUkjU1LPRWFo3kzJy/92f/Iz0IaWXzSfGtdN40mezEQSU0IADhke7o1XdAJLZglKB8Hvb9iBxn3sgnTO8gEJcihZMA== 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: Nhat Pham writes: > On Tue, Apr 9, 2024 at 7:57=E2=80=AFAM Zhaoyu Liu > wrote: >> >> On Tue, Apr 09, 2024 at 09:07:29AM +0800, Huang, Ying wrote: >> > Andrew Morton writes: >> > >> > > On Mon, 8 Apr 2024 20:14:39 +0800 Zhaoyu Liu wrote: >> > > >> > >> Based on qemu arm64 - latest kernel + 100M memory + 1024M swapfile. >> > >> Create 1G anon mmap and set it to shared, and has two processes >> > >> randomly access the shared memory. When they are racing on swap cac= he, >> > >> on average, each "alloc_pages_mpol + swapcache_prepare + folio_put" >> > >> took about 1475 us. >> > > >> > > And what effect does this patch have upon the measured time? ANd up= on >> > > overall runtime? >> > >> > And the patch will cause increased lock contention, please test with >> > more processes and perhaps HDD swap device too. >> >> Hi Ying, >> >> Thank you for your suggestion. >> It may indeed cause some lock contention, as mentioned by Kairui before. >> >> If so, is it recommended? >> --- >> unsigned char swap_map, mapcount, hascache; >> ... >> /* Return raw data of the si->swap_map[offset] */ >> swap_map =3D __swap_map(si, entry); >> mapcount =3D swap_map & ~SWAP_HAS_CACHE; >> if (!mapcount && swap_slot_cache_enabled) >> ... >> hascache =3D swap_map & SWAP_HAS_CACHE; >> /* Could judge that it's being added to swap cache with high probabili= ty */ >> if (mapcount && hascache) >> goto skip_alloc; >> ... >> --- >> In doing so, there is no additional use of locks. >> > > Hmm so is this a lockless check now? Ummmm... Could someone with more > expertise in the Linux kernel memory model double check that this is > even a valid state we're observing here? Looks like we're performing > an unguarded, unsynchronized, non-atomic read with the possibility of > concurrent write - is there a chance we might see partial/invalid > results? > > Could you also test with zswap enabled (and perhaps with zswap > shrinker enabled)? READ_ONCE() will save us from partial/invalid results. -- Best Regards, Huang, Ying