From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gentwo.org (gentwo.org [62.72.0.81]) (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 00A0627C84B for ; Fri, 13 Feb 2026 18:15:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.72.0.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771006524; cv=none; b=E6n42pn3/TpWPzZ/te+CauQkCt+oqzAHySqvInUimywtM5yNVFfIYATAqSnrsX1nr/nSEMkHuJWAa2iHCgyPi93/2S7z1PVHXrq3pYlDmqEZLY5w7KqlOpfX3VGeISX/YcM+00bR4aT9MEGmYR8iX801a+MxsQ/tM3AsBOAoIqw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771006524; c=relaxed/simple; bh=d5ft0v1DzBv7O9TUG+pJ/PxgJXbCoxM5WOAut7LedGE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=pz1JjxNessQWQSMPEFO8fhJIRcsC/0aCrTZ1O0+NwH+/zlZBObTs5OTjjNZfX+Chjc4wIDbYUkMJSaYlM2FUjhKpK74IEFZwppw9KlWbFlbY55zkJHb5kG0has9Zjd7jkoXIDcMSgTNFqIcOvgPunaNzCH3SbqB1kidK4ePUs44= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=gentwo.org; spf=pass smtp.mailfrom=gentwo.org; dkim=pass (1024-bit key) header.d=gentwo.org header.i=@gentwo.org header.b=VuQDErpb; arc=none smtp.client-ip=62.72.0.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=gentwo.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gentwo.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=gentwo.org header.i=@gentwo.org header.b="VuQDErpb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1771006515; bh=d5ft0v1DzBv7O9TUG+pJ/PxgJXbCoxM5WOAut7LedGE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=VuQDErpb0bWwWlXSkFKCR6F0iYly2rnqEyrpY16heC+ZSqk/zPlhDO1LjDmp/BBOl 9mJxC5dEBouD17xjHMfjmpiYT7Q/UtT2vza2+J1hFhrb4WgRgtY5O9IvjmEeVEoKSz un8/E+s3YtREsqcecNEJG3IbE1BLf6Cw+CCCB+5E= Received: by gentwo.org (Postfix, from userid 1003) id 6373141B00; Fri, 13 Feb 2026 10:15:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 602B741AFF; Fri, 13 Feb 2026 10:15:15 -0800 (PST) Date: Fri, 13 Feb 2026 10:15:15 -0800 (PST) From: "Christoph Lameter (Ampere)" To: Frederic Weisbecker cc: Shubhang Kaushik , Anna-Maria Behnsen , Ingo Molnar , Thomas Gleixner , Vincent Guittot , Valentin Schneider , dietmar.eggemann@arm.com, bsegall@google.com, mgorman@suse.de, rostedt@goodmis.org, linux-kernel@vger.kernel.org, Adam Li Subject: Re: [RESEND PATCH] tick/nohz: Fix wrong NOHZ idle CPU state In-Reply-To: Message-ID: <8ae7f176-2e1c-2390-a7da-a694df4b551e@gentwo.org> 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=US-ASCII On Fri, 13 Feb 2026, Frederic Weisbecker wrote: > Then there seem to be something else going on that we don't fully understand > because isolated CPUs run 1 pinned task per CPU and the only housekeeping CPU > is CPU 0. So there is nothing to balance here. > > Perhaps some CPUs spend too much time scanning through all isolated CPUs to > see if there is balancing to do. I don't know, this needs further investigation. > But if the nohz_full CPUs are correctly domain isolated as they should > (through isolcpus=domain or cpuset isolated partitions), they should be > invisible to ilb anyway. "balancing" would mean moving tasks from busy cpus (that are not in NOHZ_FULL state) to idle cpus that can then be in NOHZ_FULL state. If the move to from a busy cpu to an idle cpu succeeds then both cpus may only run one process and be able to enter NOHZ_FULL. This is f.e. the caser with threadpools used by certain AI apps. Before the app starts numactl is used to setup a group of cpus that the app can use. One may optimize and allow NOHZ_FULL for these cpus. The app will then create a number of threads during its startup phase. These should be all placed on idle cpus in the allowed cpu range. If this is configured the right way then each thread is on a different cpu and there is one thread per cpu so that we can use NOHZ_FULL. This is sometimes broken because not all idle cpus are used. Instead some cpus get two threads and other cpus stay idle. That is why idle load balancing is needed. There is no cpu isolation/cgroups or other black magic involved here.