From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazon11012006.outbound.protection.outlook.com [52.101.43.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11E3435C6BD for ; Fri, 31 Jul 2026 05:55:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.43.6 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785477357; cv=fail; b=pc2iOTLevNJ88+//fCQjtbde1l9EmZTtdteCtAKS69ibxcNt2wMwU+oWHkTgmts2Pj0cCjTxgzRrgJJZtuDClIr8IuR6ZGPLpdrvwhD9aV3Z1e7f6mZEa9OdhlpMXzERr3pA4vfxnkx9bYa7r5hCs/0xvUjIU3ocVFJYTXCnamQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785477357; c=relaxed/simple; bh=x6nLr8N1kmH63S0QI82bl5kT3kYeh+T3tV5ZQRavnF4=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=fqm5rkn3yNSe1iIOBsexlCcxcl5lku64b2vgbsRsAXBrzI0sO8X6lgTvpessC5nrcheKqJ9qp53W8rN7WA2L0YIzam7FSSShGsbo/EkJ8gxYh4DGElKOeEDNHn3DHgZw1BFrCmY63M+sH+Ac0z6cLe6nzlPqrP+PiJGWCTbSW7w= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=t0+Av7C/; arc=fail smtp.client-ip=52.101.43.6 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="t0+Av7C/" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NQoISvib+WfIEBBy4MsO/zyXb4SU33WHzKPn7pj0eDFGy6DXcikesbCRlUNyyn15No2m6WmAgPgiGMgrbROcSZAgjujfKwS7ousZwLDCleE/iV/or/rT2p7+P5dgbzpT4BI4EyfCzMtOu9DDEAz/OKkiISYPz/d+m1IV26lh4NqyPm/5xtM9MViSQwQWLPPOZhfHbS30NAROws0ZB45eJ2gH7aA5jx6fNhxNYs2eq9EStkDmxtyO2UCqfAyTZEtCRKrxlH7MQ4H4cymayaXjbmMUkxxpLxo7DRuvLILnW7wv32qdr/IvoA6OTacE+aoYCHf/YOfTOMYUokk6QHcCIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Art6Zn9eWzTULTysSMrFaBwlf4jp4KpgSfSbTf9zt6g=; b=Kqpx7NIYgfaP4DIXycqG4pLxBALqMNrOQ/Bb6kpAQw76CyP2f8qMT48Fi1fKTxcqCQPcm/xcvRaCG5Ggf4sDEcFMuJ3koZ5sWm/LQkpSH8+KIZFMe9hGkux+kFrFq7UkqPUBqoenNyZbE5Fz/XAo6vuyf+oAg1boeVt5aNyv9vd81DslqSUegQK8eLxQSNIVbq3BbSdSUtjFL5wy37/Hfuuv4RTElVf9Ckf7uJsdrN46gIS8KFrxPOvebIeGqHf1Va1NC26N4bQ9+ivOxn97D96lpsoszlZNBkOm0JnyNLtZhkrfjeSHTOC1ZuaQVGHZViNxCHlqnkzKRMt1yR2j3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=google.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Art6Zn9eWzTULTysSMrFaBwlf4jp4KpgSfSbTf9zt6g=; b=t0+Av7C/Kdh9zySwJ+U24835R/44RCFQ0ze32vhNvptR3rtIR/Lcpspg4ow5ojDAs9+gANtDxU10+ZELz+nI65BtAYtFEayLY9EYGC5ywTEljKthgazZ7mwHCC5j3hPYStXwVTlhZWr0m/HFAow0/9Dmn/Pe5unPhKOceLKFmKY= Received: from DS7PR05CA0020.namprd05.prod.outlook.com (2603:10b6:5:3b9::25) by IA1PR12MB6532.namprd12.prod.outlook.com (2603:10b6:208:3a3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.14; Fri, 31 Jul 2026 05:55:46 +0000 Received: from DS3PEPF0000C381.namprd04.prod.outlook.com (2603:10b6:5:3b9:cafe::1c) by DS7PR05CA0020.outlook.office365.com (2603:10b6:5:3b9::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.9 via Frontend Transport; Fri, 31 Jul 2026 05:55:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by DS3PEPF0000C381.mail.protection.outlook.com (10.167.23.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.8 via Frontend Transport; Fri, 31 Jul 2026 05:55:45 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Fri, 31 Jul 2026 00:55:45 -0500 Received: from [10.136.32.30] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Fri, 31 Jul 2026 00:55:42 -0500 Message-ID: <6387735d-accf-46a6-b40c-6f0619181c18@amd.com> Date: Fri, 31 Jul 2026 11:25:35 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] sched/fair: Skip NUMA balancing scan on memoryless nodes To: Phineas Su , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot CC: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , References: <20260730175151.3855700-1-pohaosu@google.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: <20260730175151.3855700-1-pohaosu@google.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF0000C381:EE_|IA1PR12MB6532:EE_ X-MS-Office365-Filtering-Correlation-Id: b66190f7-ff5c-4f25-3c1a-08deeec85d35 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700016|7416014|23010399003|376014|18002099003|22082099003|56012099006|11063799006|5023799004|6133799003|10067099003; X-Microsoft-Antispam-Message-Info: xJ4Wdv/xqicMLwKzhcjiPCikV7VfWfpiOYXAoe8fImHSQW00ESeN+gn7L8HIRyZIhCDzM9hKQw9CTWEKnXwFrAGFpbBIMcxDZcXj4ozrtR0S9aN9zdkb1QsJNCAAzMQCoDnGNhtlsA33kxQVv5JN633s2lttDhsLhisY+spv9PHg115jNXrOzl2qY2yhvLYN1vjvZOT+eroPhZJ7YX1MRAEQHYkx2UCCKG7R5r91DpvFOWAoqzNN5ySl8Ux4z2q9PueOOSYsK0zDQSUx5Ip0f+1CBZ+czkP7YGYwrJLeH9I4jruUGQp6W3QlRRKqW0r7xyt2wSEI/qcCm1KwUjFyOg/fc50LdRBJeC6rgni/4JomA2cmrDCsEumoT7LWZP6X0/ii1ga3+O9+vLuwr0C2P+6co0ORJjDmTGDnUzsbs3R5M7q+mVfM1Za9C96YIPpDzL0hTnCTjNx5Mo12Qr4h7Is0xyfrWxUFr1EbeHnFm/ltaE5aYeQCVhjoHQQTiShSlzXfyvJNaytL9OKSSMuuCNxEJ+WImud13FPboWZFVXxIKry32lD4EVIlOknqezGw6JlL2BU8zAyb9SDcAkZie7a3ucHYUuxHvSGjN6PQSEM31nMczBZD75mY3Z2/918nfvAk8bfH9Dh7CG/lhwiy1B56t397A96RouhBHgxsKHTjmnw7v1G0SRKI+cvyKPcGiSwNbhcFaNw9Wc8Jncvmfg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(7416014)(23010399003)(376014)(18002099003)(22082099003)(56012099006)(11063799006)(5023799004)(6133799003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 3IlL6tzMhsiKE+uiXuyj7GULtIsALIx1BwmVlCbOMgred9HQOtDmUCIqmc80o/23y5ObpBSoj0pQWT42Nqjabx+XaJy449F14J52lyUELJdeOyh+bN3mVzcKORW67TjJtjPvFJbv0ZYT9Pm+oJQ8iBJYU6Fas0jBpSHfWOl9Y+fPVXALXTRfZT2KOkjhYmZ6LbLEQJYyfCbRPWxJGr+jVin0d7vufjyb0TOHpYWCqgdMwZKfq4z98x4c+9amPkUO+T88uH3xvdjS7nsoCBcZRkrqrWbTwreLplhQYftrVsFyjb1gKC239D6+fXfiyNuWKon5Ld4N5V9JLFSrgmzVmpfavaRLCf49GUxvFfVY+bzYtL70BdtAyuO+wCMdIf8Rx9bHFfZobD9U8CVjhenwCI5/wEroe6WkptkiS4w8oAK8VHtSRucVRM9DG9RFEoB6 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2026 05:55:45.7257 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b66190f7-ff5c-4f25-3c1a-08deeec85d35 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF0000C381.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6532 Hello Phineas, On 7/30/2026 11:21 PM, Phineas Su wrote: > On systems with memoryless NUMA nodes (e.g. CPU-only nodes created via > memory hiding, socket topologies with unpopulated memory, or CPU-only > NUMA nodes), tasks running on these CPUs cause automatic NUMA balancing > (kernel.numa_balancing=1) to repeatedly schedule task_numa_work() from > task_tick_numa(). > > When task_numa_work() executes, it unmaps VMAs (PROT_NONE) to induce > NUMA hinting faults (do_numa_page()). Fault handling then attempts page > migration (migrate_misplaced_folio()) to the task's current CPU NUMA > node. However, because the node has no managed memory (N_MEMORY is > false), page allocations continuously fail (TNF_MIGRATE_FAIL), while > task_tick_numa() repeatedly reschedules VMA scanning every scan period. Isn't task_numa_work() also responsible for scanning? Inhibiting that can be problematic - task can perhaps move to a node which has both CPUs and memory and the hinting faults can help determine that. I feel the page migration to !N_MEMORY node should be inhibited at numa_migrate_check() on the mm side rather than skipping the task_numa_work() entirely which can still be beneficial. task_numa_fault() on the failure path there can instead move the task to the node with CPU where the hot pages reside instead of trying to move the pages to the node where task is running which, as it turns out, has no memory to accept these pages. Am I missing something? > This results in heavy kernel system overhead (%sys CPU usage spiking up > to ~78%) and continuous page fault storms without any possible NUMA > placement benefit. Now if you have a case where task is moveable only between a set of nodes that don't have any memory and the hinting fault overhead keeps adding up, that is a different problem. > > Fix this by: > 1. Checking node_state(task_node(curr), N_MEMORY) in task_tick_numa() so > tasks executing on CPUs of memoryless nodes do not schedule > numa_work callbacks via task_work_add(). > 2. Checking node_state(task_node(p), N_MEMORY) in task_numa_work() as a > safeguard to immediately abort VMA scanning if a task migrated to a > memoryless node while numa_work was already enqueued. > > Signed-off-by: Phineas Su > --- > kernel/sched/fair.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index d78467ec6ee1..214cf0f2c692 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4101,6 +4101,9 @@ static void task_numa_work(struct callback_head *work) > if (p->flags & PF_EXITING) > return; > > + if (!node_state(task_node(p), N_MEMORY)) > + return; > + > /* > * Memory is pinned to only one NUMA node via cpuset.mems, naturally > * no page can be migrated. > @@ -4391,6 +4394,9 @@ static void task_tick_numa(struct rq *rq, struct task_struct *curr) > if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) || work->next != work) > return; > > + if (!node_state(task_node(curr), N_MEMORY)) > + return; > + > /* > * Using runtime rather than walltime has the dual advantage that > * we (mostly) drive the selection from busy threads and that the > -- > 2.55.0.508.g3f0d502094-goog > -- Thanks and Regards, Prateek