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 59A58C072A2 for ; Fri, 17 Nov 2023 10:07:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62E28440167; Fri, 17 Nov 2023 05:07:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DE08440166; Fri, 17 Nov 2023 05:07:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CCA7440167; Fri, 17 Nov 2023 05:07:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3DD7B440166 for ; Fri, 17 Nov 2023 05:07:53 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0F5B2A0D5C for ; Fri, 17 Nov 2023 10:07:53 +0000 (UTC) X-FDA: 81467020026.08.DD925FB Received: from outbound-smtp44.blacknight.com (outbound-smtp44.blacknight.com [46.22.136.52]) by imf20.hostedemail.com (Postfix) with ESMTP id E06B91C000B for ; Fri, 17 Nov 2023 10:07:50 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.52 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700215671; a=rsa-sha256; cv=none; b=GhQ7873QpGFgGVKL0Jas3fUAldsW5+nFIjcJ3ofoHJMDwuVaipVWqbBSS9/gxfE6+X9sxD M1nFw+5Vrg2ybCqO946v+YckF/1y7ROnhBngvOH1u7QfT2rF2Zi6gNfGB3o87ZMmYHxHz+ IMdDeB3cC3tOixLZhTPdLervqONSK/s= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.52 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700215671; 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; bh=xBn8J/Ez+suCRdPZOaf6o61TxeFiUYpaXReY3tbHmPM=; b=fQi46891zGqdsQr7T8fq3mED3Jztod/k9m4vhY7A6O2KWwFf7SlmJqNzcTudT8O61Y39uj sTL8GSudWud+ZzV8M9Xoy0VmBmSAyNoCz9hETz2cU5TyYIySkaJsjh+kYMbFp4k3ici7D1 34Et0oc2ox395PTJuInu7EqqjJ36GhU= Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp44.blacknight.com (Postfix) with ESMTPS id D6A23F8780 for ; Fri, 17 Nov 2023 10:07:48 +0000 (GMT) Received: (qmail 31407 invoked from network); 17 Nov 2023 10:07:48 -0000 Received: from unknown (HELO mail.blacknight.com) (mgorman@techsingularity.net@[81.17.254.19]) by 81.17.254.26 with ESMTPA; 17 Nov 2023 10:07:48 -0000 Date: Fri, 17 Nov 2023 10:07:45 +0000 From: Mel Gorman To: "Huang, Ying" Cc: Baolin Wang , David Hildenbrand , akpm@linux-foundation.org, wangkefeng.wang@huawei.com, willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, John Hubbard , Peter Zijlstra Subject: Re: [RFC PATCH] mm: support large folio numa balancing Message-ID: <20231117100745.fnpijbk4xgmals3k@techsingularity.net> References: <606d2d7a-d937-4ffe-a6f2-dfe3ae5a0c91@redhat.com> <871qctf89m.fsf@yhuang6-desk2.ccr.corp.intel.com> <87sf57en8n.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <87sf57en8n.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E06B91C000B X-Stat-Signature: d14sfp9rndyk88g8cmg37b3g8nzau1ip X-HE-Tag: 1700215670-535777 X-HE-Meta: U2FsdGVkX1/EdMcKLyA34mELKXg6r+697xGeWBQsWzkPAnFA6dQJNmnzW8mrHzPC/1ewe98r4Egc6FHw5xlTndPdAnpOOBezsJ7bWhMBAD/+f2cM9UhZyki7MUMgMbq1FM/WKe5KVjlOhOHk+Jgsd5d9+kuE3h/kqKnoYQZ9zYqQnXXrgg88T49guXLHpCJ9Kh+lpn0KCIn5kaRJAMzf6izX5kGgIJROYM3hpZVfUgYM45YDX4g9XpY7I6IJ+txNm3QU3cq/vxwzoukXkGITTbcW/KMCtn8ZT3xJmlHmKbzj8pT5GSoCk0DFMVZMmq2SzzbBYfnpx0CAusmushP42sAK2qE8i+kV3r+KIUhtC/B0RBlHzohrInmSFVoP9jgeujT57dhHMxF97fDBTCtUZQAvDxX7ZrUNZ5LNvXqapzKLj9MMGlAMbD857Z3nl30bYY3EyZsxhFkKf8pGp9H5ZzXnNE+8qWmr/JUQfH+pC7zz/vkYUR/L4D4nHqjecvz5/SMBUZGUXLiAzbpw08fR0UHWlAM3Ty8VMR0Ebxuc1RXxk3oqE3gV5q8j6p688UDngn5lIh9ELk8C3J9i0/nt4iHQnGDMiyl3unHg5bgsLnUdjnuj/MszD5La+pawvXYYAuhN6cyKt7jfgI1cdY8n+T0aUGv5ogzAYSp5LRAnPvLWZ5GfiglSkXgg/xT+7MWZyvZT9/VITRIm3CS2B7t+EadY+IwKhIEoKlUqpyqUmNrE4SAwh8Etu0tXt6yIA1P2XzkhgkRv0JUxZkKttCJ7UIqspouk9SlcXeCNg7mGoiIuV1nOtp8RC8x1+S2N9sFNRszzVbySY5eCAbTjHBbIvKTTjazm7Mo3OtHUxhZiqJo4fPdYDoODgU26ZuS9DQcsutY1DwkZIkLKzaQWSM0LjckzetFirbAX5K44cGqrlAnMDzzwZEax6/2OkQint9jNT7fLhaBuL0jCyrdqyeu n1JwV/4/ l392UFBhMZbO3HJLB7HFZ5jdmZRfwq7XklKHGP4xWKAJV76K8ntkwk28sGH+I+4c1y4BmIZauZ6+RIXTl/FCjJc6iNtzRTned2WUIbPC3oHBjeuxkwf6IPrzgR6gGSXwLLkcKFhQKbXyytkXeIpcg5SLQOoe2lSOItBrmxvIPq0Q/MQETkXGvKM9BaCtqavVRPOIJG3aomjEhr8ut1DMek9sv6gcOKe3sAKtmceBDFTkH6b1gW7MKaGy7s5VNeB6ltKOh0KtPnXW5qSE= 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: On Wed, Nov 15, 2023 at 10:58:32AM +0800, Huang, Ying wrote: > Baolin Wang writes: > > > On 11/14/2023 9:12 AM, Huang, Ying wrote: > >> David Hildenbrand writes: > >> > >>> On 13.11.23 11:45, Baolin Wang wrote: > >>>> Currently, the file pages already support large folio, and supporting for > >>>> anonymous pages is also under discussion[1]. Moreover, the numa balancing > >>>> code are converted to use a folio by previous thread[2], and the migrate_pages > >>>> function also already supports the large folio migration. > >>>> So now I did not see any reason to continue restricting NUMA > >>>> balancing for > >>>> large folio. > >>> > >>> I recall John wanted to look into that. CCing him. > >>> > >>> I'll note that the "head page mapcount" heuristic to detect sharers will > >>> now strike on the PTE path and make us believe that a large folios is > >>> exclusive, although it isn't. > >> Even 4k folio may be shared by multiple processes/threads. So, numa > >> balancing uses a multi-stage node selection algorithm (mostly > >> implemented in should_numa_migrate_memory()) to identify shared folios. > >> I think that the algorithm needs to be adjusted for PTE mapped large > >> folio for shared folios. > > > > Not sure I get you here. In should_numa_migrate_memory(), it will use > > last CPU id, last PID and group numa faults to determine if this page > > can be migrated to the target node. So for large folio, a precise > > folio sharers check can make the numa faults of a group more accurate, > > which is enough for should_numa_migrate_memory() to make a decision? > > A large folio that is mapped by multiple process may be accessed by one > remote NUMA node, so we still want to migrate it. A large folio that is > mapped by one process but accessed by multiple threads on multiple NUMA > node may be not migrated. > This leads into a generic problem with large anything with NUMA balancing -- false sharing. As it stands, THP can be false shared by threads if thread-local data is split within a THP range. In this case, the ideal would be the THP is migrated to the hottest node but such support doesn't exist. The same applies for folios. If not handled properly, a large folio of any type can ping-pong between nodes so just migrating because we can is not necessarily a good idea. The patch should cover a realistic case why this matters, why splitting the folio is not better and supporting data. -- Mel Gorman SUSE Labs