From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 16BDC41684D for ; Fri, 31 Jul 2026 10:31:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785493932; cv=none; b=dEGMv9e1+Z7GMoeNQ79/SaqSsN5B8JsJ9PZaDxYenKC5llDy649RYaEVHrmWYiCqdpNpO5v+UNLbwlDUwrGPuXYALQj9SYB7g5xdgiVgjK7Y3Aaw1ODEn56+rt8+DQur2QM4kYl+0+9SLeKiPKNYdAFlGGDJ65VLetjqymDU8B0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785493932; c=relaxed/simple; bh=0cbTlgLX05k+ez4x1hadTcBQYbRlp+LtD9yG3XSWFUQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X6ki7U9pUpvQcHak+e01eMyouU+FnICiYNtQI6pb96LZE0FdBJPkPT4OiDFsd8oAjMK09qSL+6CFz9PHYFbWmlKAOHbPA/s34iViTMRoG6CzKSfhXs1fENDxxZ0C7Sdzs2DjghSa1KadcLbUPI5RNjTkA5wPvBQuMr0V4IqO7mk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=En8oyfZ0; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="En8oyfZ0" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=bmh49ICiNGQp8RX0Q8L4M/ZWvYffj11y/7zKzNAIkng=; b=En8oyfZ0ObqZiSIhmlksJTgEdp GA/CrpCwqWyLeJc+xcVUjSmuiSgKOf30yv8BPNjdtHOpGV59tjxPhJv2Ffvw8Wx20CP3QMXazxFg/ OS2a+zefhCIOX2i6b73KtGeSHpAUvoLTIAROjWeQn8YuWp7Mhgg6MO5XqiItwAyRuYOl/fIO5MdJ/ lxM/NQ/7QGo+V2Re8yOQCqhFAmPMPmrgD3TnAwjidT8rdTLHrtPZNFqT3g/a5kbdLDdt0NK6WYi5M hPEbX2mmbFAQ+OJQ+Pmng5A18QJ7DlhkR8KyFk2o9IVqAmFgnL+uRj6wR/ZPAxMKYbstvB70LAQAx WwKm6SgA==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wpkWg-000000018Mc-12DS; Fri, 31 Jul 2026 10:31:38 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 6709530093A; Fri, 31 Jul 2026 12:31:37 +0200 (CEST) Date: Fri, 31 Jul 2026 12:31:37 +0200 From: Peter Zijlstra To: Phineas Su Cc: Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/fair: Skip NUMA balancing scan on memoryless nodes Message-ID: <20260731103137.GR49951@noisy.programming.kicks-ass.net> References: <20260730175151.3855700-1-pohaosu@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260730175151.3855700-1-pohaosu@google.com> On Thu, Jul 30, 2026 at 05:51:51PM +0000, 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. > 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. > > 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. Rather than fully disabling, I would argue the right thing is to ensure the pages are nearest the node the task runs on. That is, rather than force migrate to *this* node, ensure they are on a node such that the distance to *this* node is minimal. After all, the tasks still run here. Not migrating the memory just because this node doesn't have memory might mean the memory stays maximally far away, which is suboptimal.