From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5BD8283FDF for ; Wed, 28 Jan 2026 07:27:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769585235; cv=none; b=FGXsZy9UgFRI/oNIDCPEUp6leu8U70HCTDCloz4A7cUeEydTswTeRWDQz/SMUIesuz5ZR+K3tnPsvX63Nkoj3WYDf10CnRuo8DBrxfh1AzcnfxhzwNshi4n3WNEoD8IkhypJva8USiqIkhtPd1PwTvhB7kmmQHXCuhYK2JAg1kU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769585235; c=relaxed/simple; bh=jlXRhGma27jEjJz/U0mqPmBp8x0DKFukOEAsDbGabuI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pxXru7dHjFQORsNbB3gGSP2JGlDd2cG5ONWkbPGNQ0pEcev1yn7qrWJUO4s9Sgks1U0ybWz+4wqGJ2crGsJnsEgoP+b2pu0ArVKMGkmhKwHpPvp3w4T33Sqi7GITjjiGvzGXhLzzExSyM5185OVQcB03rqAW3gcErm77o6fUUBA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=m53gpwjb; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="m53gpwjb" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-47edd6111b4so73342655e9.1 for ; Tue, 27 Jan 2026 23:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769585232; x=1770190032; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+HA5vFIDa/zJ9zYcXnT9UEgxVY2Ax0YFdoY3zS+eJss=; b=m53gpwjbF2E9KQ8W0uK3YUpQtOszAIWHmzE4P2gi+XuPmfyXLp+MxeBGI2o0fk8o9C FeoAW43hgF1YziCyQzIUwcQALB/l7r5H+1S1154DnUdWmd+MfprmFrHggGrREm4DYe/m q8xT3tnz42wgzY4+wS2jtzG5f3yLkD/+aZ8j3I8/WsFEWFZeAihk+m4GZviIvMbuq0Df jZyNwYxoB04XjCsEinQSgRh1N5tIDtwxnCzQd8M0TBTIIEEPFpmjVS4mwr6x7+pn15/I TjD8oXHh0NWpXzyOHcBphd5XoLOR8YlE+is071wH0j3qFh0LDTEVw1ctmkBDo5oEI0cJ GZ9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769585232; x=1770190032; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+HA5vFIDa/zJ9zYcXnT9UEgxVY2Ax0YFdoY3zS+eJss=; b=A0a7gG2BPAqZ1xfE567llaHLwT84U20pqB3Ck+xpU1EY16KjodZGEm1Cl66hjeQ1vM KOKvWidquVCayAV0PpgSjuos/hAhX+BXi4K4tgv6qihFPZw3qI8LvEEEwhUpEyAUYq6f umQD9PD3qz/DR9pxVgoURbwgtOKA60Jj7iLvqaT12ftO2z5MMm+4XNEntxNLw45ZVVQy fIIvQrJIB9/NJWM2gN6cLmEuQE1OrLcx6gcs4GhsS1VgLFbpY04erOn3tNkPxEBftjwo mmiTy9bKw2nF8uRRRpTXblGwsKgcHvzI7GcCNV91PwxVxRNteetasBrHiO6oaOzZj1nD eqzg== X-Forwarded-Encrypted: i=1; AJvYcCXhhMF620XSUmnVvbezhmCa4+avmO5gWJPLcKZBfRmA9Ac9rYpZ/BeZLXKMNFIHlWS2DzvvbecH/AGF/kM=@vger.kernel.org X-Gm-Message-State: AOJu0Yw94Qbq+faXBCUVTDRu95OtOIxEbUXv0ieJtty5+TekL1e2Unuo jttQOc0R4AI2aWfoNBMi2jGVu81dLRK+KQVR9rpqhlf2g9P59UBQiSzICe0lVdEP X-Gm-Gg: AZuq6aIS+N8NZEjUbrLtv7XT9j++JpfFLUMF75grbpuBk38vOLHRY3ITLrQxAxHfOX/ VVKmIdB+XKtxCfVgz9sSF/2c+Pr6m8Sd9XBBkasVxPZkE/81Bkov2ba8HznnHOaud/83UAyae25 6c6F8EK0pfiOQSfDuZ2xcq7jsweLq94fQJlPfzOHpkSdmJuPLsCEFf2JfPKj4Pz6XTZrLSsUnPJ viK16IFOvw5CfcPvF2s4fwJeaPLsLrPxT4vHxrtghe4Pn8/iV+KTT+LnZ5MalQW9qV6VNwZlkjG 2pQrLMc7oyDcKbcaItiIxaQKmF6BsGH6Nmk/5pfkr1cncr4P9AyWK/DxhSR7YSCWdQhV9lwzpSo G0dSCj4xV2xcEEXSVwc/lPERbkjUbAUxUFsmgM4pANuQgA6fTDf7lHqwUICenH1ap5IACOPKETD lTJYm/iQm3AWn12bjqn/Xt8wfD+vUalZ7V4Rmd6GQ= X-Received: by 2002:a05:600c:4f06:b0:475:da1a:5418 with SMTP id 5b1f17b1804b1-48069c0fdfemr54153435e9.1.1769585232026; Tue, 27 Jan 2026 23:27:12 -0800 (PST) Received: from ionutnechita-arz2022.local ([2a02:2f07:6017:b500:fda1:539e:7acb:2db8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c37420sm121590645e9.9.2026.01.27.23.27.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 23:27:11 -0800 (PST) From: "Ionut Nechita (Sunlight Linux)" To: frederic@kernel.org Cc: anna-maria@linutronix.de, ionut_n2001@yahoo.com, linux-kernel@vger.kernel.org, mingo@kernel.org, sunlightlinux@gmail.com, tglx@linutronix.de Subject: Re: [PATCH 1/1] tick/nohz: Add fast-path tick stopping for idle isolated cores Date: Wed, 28 Jan 2026 09:26:57 +0200 Message-ID: <20260128072658.6925-2-sunlightlinux@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: <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=UTF-8 Content-Transfer-Encoding: 8bit On Tue, Jan 27, 2026 at 02:40:08PM +0100, Frederic Weisbecker wrote: > Le Tue, Jan 06, 2026 at 05:36:48PM +0200, Ionut Nechita (Sunlight Linux) a écrit : > > 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. > > Most of the idle code is under TS_FLAG_INIDLE, and the can_stop_full_tick() > path is then not taken. You're absolutely right about the TS_FLAG_INIDLE observation. Looking at tick_nohz_irq_exit(), when TS_FLAG_INIDLE is set, the code path goes to tick_nohz_start_idle() and can_stop_full_tick() is not called at all. I need to clarify: the benchmark results showing the reduction from 8K to <500 LOC interrupts were measured with *workloads running* on the isolated CPUs, not with idle CPUs. The optimization was helping in the non-idle path where can_stop_full_tick() is actually called via tick_nohz_full_update_tick(). The commit message was misleading by focusing on "idle isolated cores" when the actual benefit was for nohz_full CPUs running workloads. > 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. Thomas suggested a cleaner approach that optimizes check_tick_dependency() directly by returning early when tracepoints are disabled: if (likely(!tracepoint_enabled(tick_stop))) return !val; This is more general and benefits all contexts, not just nohz_full. It avoids the per-bit iteration when tracing is disabled, which is the common case. Thanks for pointing out the idle path issue - it helped clarify where the actual optimization was occurring. Thanks, Ionut