From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 3F32D223323 for ; Fri, 13 Feb 2026 13:11:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770988298; cv=none; b=nPcgJisPNhLMEfDZkCOM0Sn4f9TP3SNu6a0Q1lUGk9ksofqRcbwZ3GLUNN8n4RbH+ooOhk9RU88LV7buOXWhRx0eD6TlqyU+RBCAFroDpI0aX5JEUDz6cOW5c6mBXcyKJ99V/JpxHlKx3KT2g8S92yO62TgGJdK3Yi1//qRngG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770988298; c=relaxed/simple; bh=UeB9bJLehALdCxJ0ELugsbOQAC2TcN4n0on+zep9KnE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jAp/zbeUAosTyBe+cky9CMyPvtMLe7l1uxZnn5F0DcR5XN4C6AnwULIerkQInxh03BAUgg2wn5FEqIMZH5O89sOJi9X6HBKIbXfJEDzTeEcbo7hz0+LaqgG2p+JS+i1q4WplhRFZ5w+Haacq/KwGesLgSRW8c/zaWa83MRLdr60= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=REeLoH9z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="REeLoH9z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54236C116C6; Fri, 13 Feb 2026 13:11:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770988297; bh=UeB9bJLehALdCxJ0ELugsbOQAC2TcN4n0on+zep9KnE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=REeLoH9zv/jrLhkn2r/LeEIPFiWnU7GgF2IdzoxPTrULoIU1W2Lg/LPIOFoX634yJ 5//I2H/9qS63qNffEOiM50kxA+W+OYP+poyfqYoqhS0uuGcAErGjp8cKAdkiVEd7NW Y2OZ2c/fvvr8iQ0iBLHxfyZo1dTQ+bMLYKEQq8LMSupNFB/Vcf9Aue4SHJj2VOCMl9 YHdooBRS1+ifhDCwd1EqYQa8+lGgWUxwrmBaoflaQLS9X3lnNe9I8Cyb5w7hMWwtdq ytivfJ4Fk2GEQuHoqOl5Cm4tYixAFgkZvsvu4MNsjOipdTurPFG4bonhyQf6k+Rs3X jHd/wIusj/51g== Date: Fri, 13 Feb 2026 14:11:34 +0100 From: Frederic Weisbecker To: Shubhang Kaushik Cc: Anna-Maria Behnsen , Ingo Molnar , Thomas Gleixner , Vincent Guittot , Valentin Schneider , dietmar.eggemann@arm.com, bsegall@google.com, mgorman@suse.de, rostedt@goodmis.org, Christoph Lameter , linux-kernel@vger.kernel.org, Adam Li Subject: Re: [RESEND PATCH] tick/nohz: Fix wrong NOHZ idle CPU state Message-ID: References: <20260203-fix-nohz-idle-v1-1-ad05a5872080@os.amperecomputing.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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Le Thu, Feb 12, 2026 at 12:04:11PM -0800, Shubhang Kaushik a écrit : > On Thu, 12 Feb 2026, Shubhang Kaushik wrote: > > > > Because you rely on dynamic placement of isolated tasks throughout > > > isolated > > > CPUs by the scheduler. > > > > > > But nohz_full is designed for running only one task per isolated CPU > > > without > > > any disturbance. And migration is a significant disturbance. This is why > > > nohz_full tries not to be too smart and assumes that task placement is > > > entirely > > > within the hands of the user. > > > > > > So I have to ask, what prevents you from using static task placement in > > > your > > > workload? > > > > Actually, the llama-batched-bench results I shared already included > > static affinity testing via numactl -C. > > What I mean by that is even when tasks are strictly pinned to individual > cores, the performance gap remains. > > IIUC, the current implementation assumes tick-stop and idle-entry are > coupled. While this holds for standard NOHZ, nohz_full decouples them, > causing idle CPUs to be omitted from nohz.idle_cpus_mask. > > This hides idle capacity from the NOHZ idle balancer, forcing housekeeping > tasks onto active cores. By decoupling these transitions in the code, we > ensure accurate state accounting. You mean housekeeping tasks are moved to isolated CPUs? With proper isolation setting (ie: domain + nohz_full) this shouldn't happen. Thanks. -- Frederic Weisbecker SUSE Labs