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 F0FBF3596FB for ; Tue, 27 Jan 2026 13:40:11 +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=1769521212; cv=none; b=WaWRNx/h0WHQ0oSDIBEDmKE/hSWIzOXjDJwdQJcfvQQ1envPJmNtirHfUkdPUsmeHDIH3sbVjXdY2kJ8/2VknOR+BLX9My9JDEFyU5dxkiogSSZCBTy4Z3KrvzELuy1BS6hk9UReAxqPYKf+zmB2fZmIhL1tmFtF0GtUwWBixps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769521212; c=relaxed/simple; bh=cRw0aQbpuc9k09oyEbtN2Q/1L8VMWv1kl3aXDE0vKZE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HP9dMP36LZ6+lz6y+h1LcnKELvGSqD9yp7OOeRgXps556VRfnsbDonMLleb9vITgzV2HUiyFJpJGlZqcOqSpG7pjqQ+Cz/6/FtnOYpkAvxonDuELhNoXcBi7gKqsTNPmjKo3zT8Rj9Lv3rfj2FQkwUucBQvvALhzdtSVbt5+rJo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=peF1sC9D; 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="peF1sC9D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46E93C116C6; Tue, 27 Jan 2026 13:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769521211; bh=cRw0aQbpuc9k09oyEbtN2Q/1L8VMWv1kl3aXDE0vKZE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=peF1sC9DWXlAU1DbKOjK07prkA02d3QknGS/08Q7NewmgFf4AaeYIjG6eTDzR8hwS FdHNbZGzr+mq2O2iqcTg3OYAkxlN19mr8m3nhn9N39mjvbX4xcQOJzQnOulbwNu5e2 Z9Vshhj84Y+sgbMpZt5vrxPIkaqTFZhlhKMDuvzbLduW+0ZcMaY8Bt0Xss8BLdgkJS Jf6JSmr0sxFq6RFzZDNe4o1Oo74iYGRxWEEknzuvAT3Nwmg+eKXfjRBd6744hT8tq9 bMqOjgKn2Pf4X45VhxkrkbBr+iqo49gzaidQfrUhKIlppEg6fp6irDRWKEa1VsYsVO eR8nwEfqP09uQ== Date: Tue, 27 Jan 2026 14:40:08 +0100 From: Frederic Weisbecker To: "Ionut Nechita (Sunlight Linux)" Cc: Thomas Gleixner , Ingo Molnar , Anna-Maria Behnsen , Ionut Nechita , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] tick/nohz: Add fast-path tick stopping for idle isolated cores Message-ID: References: <20260106153646.23280-2-sunlightlinux@gmail.com> <20260106153646.23280-4-sunlightlinux@gmail.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: <20260106153646.23280-4-sunlightlinux@gmail.com> Le Tue, Jan 06, 2026 at 05:36:48PM +0200, Ionut Nechita (Sunlight Linux) a écrit : > From: Ionut Nechita > > When a CPU is configured as nohz_full and is running the idle task with > no tick dependencies, we can skip expensive dependency checks and > immediately allow the tick to stop. This significantly reduces timer > interrupts on properly isolated cores. Most of the idle code is under TS_FLAG_INIDLE, and the can_stop_full_tick() path is then not taken. > > The patch adds: > 1. Prefetching of dependency structures for better cache locality > 2. Fast-path optimization for idle isolated cores with no dependencies > > This benefits real-time workloads and latency-sensitive applications > by minimizing timer interrupt overhead on isolated CPUs. > > Benchmark results show isolated CPUs can achieve <500 LOC (Local timer) > interrupts with this optimization, compared to ~8K without it, with > best-case scenarios achieving <125 LOC interrupts on well-configured > systems. I guess we could indeed optimize further outside the idle path. But I'm not sure this is a good thing. After all, the point of nohz_full is to run things with the tick stopped. The only part that should run with the tick is setup and preparatory work, which doesn't really needs optimization. I'm even tempted to say that the tick code is a slowpath on nohz_full. Thanks. -- Frederic Weisbecker SUSE Labs