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 1B9BDC54E5D for ; Tue, 19 Mar 2024 07:28:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30C9B6B007B; Tue, 19 Mar 2024 03:28:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BCA66B0082; Tue, 19 Mar 2024 03:28:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1846F6B0083; Tue, 19 Mar 2024 03:28:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0A7446B007B for ; Tue, 19 Mar 2024 03:28:09 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 67C9512107E for ; Tue, 19 Mar 2024 07:28:08 +0000 (UTC) X-FDA: 81912959856.26.FE67788 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by imf20.hostedemail.com (Postfix) with ESMTP id D22D21C0002 for ; Tue, 19 Mar 2024 07:28:05 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LdcsK34M; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.18 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710833286; a=rsa-sha256; cv=none; b=g6zP+W9b6nkmWbQSsFn25buVrkiIoF19wUkvbOPslkcTiIFQNiYLIqAxvUUPvBPkkvp3jp NgKQg4gVp6K+k8LIjaSjPPvJrntrIzhmv8te4vOHtorc4wyJwa3/O62rhfSyjsTR3uDAHa sWzhXFrfHeGPHr8elWi0eqlvwpWDEuo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LdcsK34M; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.18 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=1710833286; 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=mQVd+9kBNTRpyb4vrgG7VohfHPUA3/RsQuDoVMmBUkc=; b=LNOe9tJifEUTRuUyuXrh4KrjgWoX3ztmRqxPRU91J/ShgGVSKcwPzyxC+KGgIykav13zuq DZ3SpUEThQJuv9wVL2H24x7B9QMlA3S+R9Kb6gI60II2oFFXbc6Bz7iH1fe9TbD508pc2E m4aINbphxC65VsEGiRttPrdY/bzvPQM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710833286; x=1742369286; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=FImFzrjqHBVVOA7dU39YkUTetJNlBqVKjjYLN+R7wTU=; b=LdcsK34MmMmb5El91DA/VoGLuYAfqgLzdToXJvqkBnMx/yqkpLqVXlmU YLhMb6+f5yiHVoIb6R/TtesNqqqFeAsOb4AClwQ+10RLTA7hin94LS5N7 pqhz+lcRcV8D5fgmXyud+7lERgHegaC4JoHb6gcbJI3gqh6sp9FQh413S /LcJjyf0K3EsZSEqS86rHB9yLpom07tBcoC1EAzmSqdajjHPneXCt7AZ9 cnpL/WjyuJ1idMf+yPjTWOsfrcFbETrCSdaQID0UtnPLBdzKr5o0AE1a7 iLIxa35O+uId5XeqTUz58I+/TCWJaYzumbhGn0q8A5hPrrHDkLc3J6Gpp g==; X-IronPort-AV: E=McAfee;i="6600,9927,11017"; a="5519396" X-IronPort-AV: E=Sophos;i="6.07,136,1708416000"; d="scan'208";a="5519396" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2024 00:28:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,136,1708416000"; d="scan'208";a="18300377" 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; 19 Mar 2024 00:28:01 -0700 From: "Huang, Ying" To: Baolin Wang Cc: , , , , , <21cnbao@gmail.com>, , , Subject: Re: [RFC PATCH v2] mm: support multi-size THP numa balancing In-Reply-To: (Baolin Wang's message of "Mon, 18 Mar 2024 17:42:35 +0800") References: <903bf13fc3e68b8dc1f256570d78b55b2dd9c96f.1710493587.git.baolin.wang@linux.alibaba.com> <871q88vzc4.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 19 Mar 2024 15:26:07 +0800 Message-ID: <87sf0mvg1c.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-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D22D21C0002 X-Stat-Signature: 8ia4rnkoz49xp7kg43xyarwpz77yusop X-Rspam-User: X-HE-Tag: 1710833285-845466 X-HE-Meta: U2FsdGVkX197A94JARd07ZdWJAF4jgkJXaumT/qE1vaCmPkbYpOIgoUHhwtrcmeSlr1PWnfazxPVLfMnuLYnbB7SGkNCwwjUHnY3Ulq5Vn4sCi0NPMRH0s48cS4lfirTLKF37ySMrKS2xxDGuCyaDPVdNPd/4l2ibL2hJnK+IplPu156jP7cCI1QzU2fpgMI1Lx9PiKTCraGlJJyQ64SBnht333T+12qVe8NsgWAvjLLDkcLo3K2yLx+4/RMoqHJSe4lBFkyGmXErFc8WIKyepWsVBS4TTDeMtwypVULRWB1H3qPRjKIYL+xLYvvTYjQOEwM4npvHkbPbirWfDJwvm6f/0q8K0lyiqs7iyJBrc37ww8+VgQVUDREz4nw6RfkjomGj18IedSKfG9sQJR9H+Vr+g/YugUDz/+l1+9OIG4fXai8csUP4ueSAGthJDvEZh7rsDZTvUNoou7TDc8v6DkcGSoRdGdIwLJAbgLSSFVG6wR6et4/VfJrb2DmjqjclBFsxEyjFFlVPW0P8tsoCdBXyjsYZ3vthOhkZ6g5uln3zYha8PN4vJ9FJI4OCzK0tyabMk60PTR2u18M6EIV3VKdf03jWoG1LaIYtDJB0rS+4YVnn6vfm5G1xMXWmqwCQZjneq63n5GnFVkYw5JjMrPyWK16oGbsNk3MveRSBnObDEvzuFmL7VZHag3TEci9RXuMSeL4z4cB2vK5NiUZvn1khRrLtiIOlF7jsnKhI2BHATEJBsSAimJEZckfFb1U+N7pVi6iIxMzRV8WNp633SBzP2oKXxRkFTfDnP+9NnsWg5qqZ+yBfwyMvrqrfeJGstEmbbrNG6hXYWI3S8hj4ll1PYJ6IPRU 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: Baolin Wang writes: > On 2024/3/18 14:16, Huang, Ying wrote: >> Baolin Wang writes: >> >>> Now the anonymous page allocation already supports multi-size THP (mTHP), >>> but the numa balancing still prohibits mTHP migration even though it is an >>> exclusive mapping, which is unreasonable. Thus let's support the exclusive >>> mTHP numa balancing firstly. >>> >>> Allow scanning mTHP: >>> Commit 859d4adc3415 ("mm: numa: do not trap faults on shared data section >>> pages") skips shared CoW pages' NUMA page migration to avoid shared data >>> segment migration. In addition, commit 80d47f5de5e3 ("mm: don't try to >>> NUMA-migrate COW pages that have other uses") change to use page_count() >>> to avoid GUP pages migration, that will also skip the mTHP numa scaning. >>> Theoretically, we can use folio_maybe_dma_pinned() to detect the GUP >>> issue, although there is still a GUP race, the issue seems to have been >>> resolved by commit 80d47f5de5e3. Meanwhile, use the folio_estimated_sharers() >>> to skip shared CoW pages though this is not a precise sharers count. To >>> check if the folio is shared, ideally we want to make sure every page is >>> mapped to the same process, but doing that seems expensive and using >>> the estimated mapcount seems can work when running autonuma benchmark. >>> >>> Allow migrating mTHP: >>> As mentioned in the previous thread[1], large folios are more susceptible >>> to false sharing issues, leading to pages ping-pong back and forth during >>> numa balancing, which is currently hard to resolve. Therefore, as a start to >>> support mTHP numa balancing, only exclusive mappings are allowed to perform >>> numa migration to avoid the false sharing issues with large folios. Similarly, >>> use the estimated mapcount to skip shared mappings, which seems can work >>> in most cases (?), and we've used folio_estimated_sharers() to skip shared >>> mappings in migrate_misplaced_folio() for numa balancing, seems no real >>> complaints. >> IIUC, folio_estimated_sharers() cannot identify multi-thread >> applications. If some mTHP is shared by multiple threads in one > > Right. > >> process, how to deal with that? > > IMHO, seems the should_numa_migrate_memory() already did something to help? > > ...... > if (!cpupid_pid_unset(last_cpupid) && > cpupid_to_nid(last_cpupid) != dst_nid) > return false; > > /* Always allow migrate on private faults */ > if (cpupid_match_pid(p, last_cpupid)) > return true; > ...... > > If the node of the CPU that accessed the mTHP last time is different > from this time, which means there is some contention for that mTHP > among threads. So it will not allow migration. Yes. The two-stage filter in should_numa_migrate_memory() helps at some degree. But the situation is somewhat different after your change. Previously, in one round of NUMA balancing page table scanning, the number of the hint page fault for one process and one folio is 1. After your change, the number may become folio_nr_pages(). So we need to evaluate the original algorithm in the new situation and revise. For example, use a N-stage filter for mTHP. Anyway, the NUMA balancing algorithm adjustment needs to be based on test results. Another possibility is to emulate the original behavior as much as possible to try to reuse the original algorithm. For example, we can restore all PTE maps upon the first hint page fault of a folio. Then, the behavior is almost same as the original PMD mapped THP. Personally, I prefer to use this as the first step. Then, try to adjust the algorithm to take advantage of more information available. > > If the contention for the mTHP among threads is light or the accessing > is relatively stable, then we can allow migration? > >> For example, I think that we should avoid to migrate on the first fault >> for mTHP in should_numa_migrate_memory(). I am referring to the following code in should_numa_migrate_memory(). /* * Allow first faults or private faults to migrate immediately early in * the lifetime of a task. The magic number 4 is based on waiting for * two full passes of the "multi-stage node selection" test that is * executed below. */ if ((p->numa_preferred_nid == NUMA_NO_NODE || p->numa_scan_seq <= 4) && (cpupid_pid_unset(last_cpupid) || cpupid_match_pid(p, last_cpupid))) return true; But, after thought about this again, I realized that the original PMD mapped THP may be migrated on the first fault sometimes. So, this isn't a new problem. We may "optimize" it. But it needn't to be part of this series. >> More thoughts? Can we add a field in struct folio for mTHP to count >> hint page faults from the same node? > > IIUC, we do not need add a new field for folio, seems we can reuse > ->_flags_2a field. But how to use it? If there are multiple > consecutive NUMA faults from the same node, then allow migration? > >>> Performance data: >>> Machine environment: 2 nodes, 128 cores Intel(R) Xeon(R) Platinum >>> Base: 2024-3-15 mm-unstable branch >>> Enable mTHP=64K to run autonuma-benchmark >>> >>> Base without the patch: >>> numa01 >>> 222.97 >>> numa01_THREAD_ALLOC >>> 115.78 >>> numa02 >>> 13.04 >>> numa02_SMT >>> 14.69 >>> >>> Base with the patch: >>> numa01 >>> 125.36 >>> numa01_THREAD_ALLOC >>> 44.58 >>> numa02 >>> 9.22 >>> numa02_SMT >>> 7.46 >>> [snip] -- Best Regards, Huang, Ying