From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 74B3F1DEFE9 for ; Tue, 13 Jan 2026 13:20:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768310441; cv=none; b=o4LDV8SzH+CLPfciQfA7pBgf3rF5Hxp8mvJw6iBIRLjvVRgMgbY9A7bKwG/hUlbJkchHZQVGtvvLaOs2k04QyQThq/YcIWg3h6ToSQd6Og9IDO0P6h7k2Y1ma8vlyPGNcSXXtu28rAuy3IIjcGgoFU/0Jlvogpf6u3JP57dn3NI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768310441; c=relaxed/simple; bh=MtaKtCy38boSMdQBBlWXiKIAit2lRtUrpwdrGzsnZzU=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Ife0w5hbCV48sf4no5WMfaBKjMp8aCYfPplQvTY1rpf7u8uln8ZIw/srk5Ze1WjYXwkXRpHsrvUsQPGDX+Rm0wIhjelFr66JKShRibyHtK5yqX6mT1aJgSVQjdIMtKp2EV3pSO3QCpVYrlwK6iMZdclxJowMDJTUJ9xU5wMGsw8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=iuKwG2M9; arc=none smtp.client-ip=209.85.208.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="iuKwG2M9" Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6505d141d02so12054770a12.3 for ; Tue, 13 Jan 2026 05:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1768310438; x=1768915238; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eTNebByZrpIFpgMS1/X78pBpL/pT/CwzNnG9Lvwn2o0=; b=iuKwG2M9/DanTfc9QB/aCMS8xjaK2u45PR2ufcYMWqUdCZ9pQPbMWZjIrMStKU5OuE 81PFAKeu0qtLyczbR0C1F4lTI9SJlZ8MTut+dGf4v9XyXl7me+KGN2YDlUJlmUdrHYUY H+aeGH9EAEKZYEGswbEMqKOULrLDxKcd6xxSIHAA08sXc2omM9+JCzxJhm/ZxR1cpocS WQccTh/K37NaH60OBg87yTGK5Mqxr3N7V4YWNmmUadyYxID8NkDU1+i9Fk07QO0ECOGi STGwFpxfmGr63J5pplJSBaZPlCYkypZi0e9bSfyqhiuV1GRIX2RBOQMf6OtK9sFp1Tea oF4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768310438; x=1768915238; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eTNebByZrpIFpgMS1/X78pBpL/pT/CwzNnG9Lvwn2o0=; b=tx7AReuv2YYt7+nENfChRI1uCMTbIA8um2ZZ1rgIsffSj5pCgIUg51ntJNtghMg/dY YyoKPwvCHNqVJlTmMET30t4PK+nbGyKn56y3xvNcuC1NAR8uVUyvrMIZmP6ZnUQ6Ean5 qVONQg00mHDBJD/mmWbTRaisUp41zeE+8dlddQ5tF+tnUzvengboghnlFHKoadkd7ZK0 qoh2jt73ykLHeDl/MzxRLLWPZFbH+d39YzwpQYji4buKrEnoUCOP8aTshMw77VfKJxYe dH2Vk0IBo7FZPKFJmx7x+3Evf3tFsSlUvkzUVJAJtIqNCofAWEb2hvSARRPjBLtX7hc3 AJpw== X-Forwarded-Encrypted: i=1; AJvYcCWfZIkRmW7RfKJk/lF7TdEoniEv/iVF+Qw/xrePg86DExQGmy569xZW9NNnoQaYxlQG63p0YbZFa2aHJAo=@vger.kernel.org X-Gm-Message-State: AOJu0YylkpyoHgfHX+VYAVj45deEQty5xfTBx4xa9rKKrNg4s4FwOjAX lNlxR+JxPfrNLzBAFNLyAV/isESpGSO0iq+TKiJAVE5HYE6uJKF51YEg4qARVLpszlClZtA6zaL rcZMu7C3Bshqwhr2sKLfxKYbwIXy2ON2BwjGTzwT+Ww== X-Gm-Gg: AY/fxX6TjtK3JWWj37VQw5BE+kOnSLqWDM+ORDjvjm4AbEnr6A0KY4ahfDlpRpFbDe9 exl5zCiRAs6yXlQH57trKBCrzVqdCELHs7jMUxHtfM8iwqhq3PlztRTZXkqIhPD41h1zptYfujn IZskU+2lxey2ZZUxRz7xkVEZ+Vu8KKG78Or5eE2Kl+9qXDdUIUP8IGg7Efot7yVTiG09eph432w VgYWvfxOjocWjgAxJzGb7RcCyIBJP6g/1ZseUYsBXHWBVYG5Xzb8WCYqRbT+qfV5uKyT7gcihxH mKyKV8Qc5+ft8Qtf3DJBDgS9 X-Google-Smtp-Source: AGHT+IGW1e6kiJQiq1eVEclg3M+UJ2A7YJ/bgNCED2uOMKOmvWOD61c40SPbjuqoCGdrj2nE1tnBo0+NSyBGSIfhbYE= X-Received: by 2002:a05:6402:430c:b0:64c:e9b6:14d6 with SMTP id 4fb4d7f45d1cf-65097e6c2e1mr19845258a12.25.1768310437766; Tue, 13 Jan 2026 05:20:37 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260112050442.138446-1-sshegde@linux.ibm.com> <20260112050442.138446-2-sshegde@linux.ibm.com> <134bdd32-6ca9-4860-9c3b-786411fadbe9@linux.ibm.com> In-Reply-To: <134bdd32-6ca9-4860-9c3b-786411fadbe9@linux.ibm.com> From: Vincent Guittot Date: Tue, 13 Jan 2026 14:20:24 +0100 X-Gm-Features: AZwV_Qh9WR1u-vEfY8-mZjiKIPltIAHNqXHvViQPQzDBwTsoGmvSqTjt2wkNP44 Message-ID: Subject: Re: [PATCH v4 1/3] sched/fair: Move checking for nohz cpus after time check To: Shrikanth Hegde Cc: mingo@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, kprateek.nayak@amd.com, juri.lelli@redhat.com, vschneid@redhat.com, tglx@kernel.org, dietmar.eggemann@arm.com, anna-maria@linutronix.de, frederic@kernel.org, wangyang.guo@intel.com Content-Type: text/plain; charset="UTF-8" On Tue, 13 Jan 2026 at 12:18, Shrikanth Hegde wrote: > > > > On 1/13/26 3:51 PM, Vincent Guittot wrote: > > On Tue, 13 Jan 2026 at 10:23, Shrikanth Hegde wrote: > >> > >> > >> > >> On 1/13/26 2:37 PM, Vincent Guittot wrote: > >>> On Mon, 12 Jan 2026 at 06:05, Shrikanth Hegde wrote: > >>>> > >>>> NOHZ idle load balancer is kicked off only after time check. So move > >>>> the atomic read after the time check to access it only when needed. > >>>> > >>>> When there are no idle CPUs(100% busy), even if the flag gets set to > >>>> NOHZ_STATS_KICK | NOHZ_NEXT_KICK, find_new_ilb will fail and > >>>> there will be no NOHZ idle balance. The current behaviour is retained. > >>>> > >>>> Note: This patch doesn't solve any cacheline overheads. No improvement > >>>> in performance apart from saving a few cycles of atomic_read. > >>> > >>> But won't these cycles be then wasted by calling needlessly kick_ilb > >>> > >> > >> when there are nohz cpus, i.e nohz.nr_cpus > 0, there is no change in codeflow. > >> > >> Only when system is 100%(which is expected to be rare), nohz.nr_cpus == 0, > >> then it is expected that has_blocked_load = 0. So flags shouldn't be set. > > > > The way we are setting/clearing has_blocked_load vs > > nr_cpus/idle_cpus_mask implies that it's possible to get > > has_blocked_load == 1 but nr_cpus == 0 although it's a corner case and > > not a default behavior > > > > No CPUs are idle: nr_cpus == 0 > > > > CPU 0 enters idle > > - inc nr_cpus and set idle_cpus_mask > > - set nohz.has_blocked > > > > CPU0 wakes up > > > > Tick fires on CPU0 > > - dec nr_cpus and clear idle_cpus_mask > > - nohz.has_blocked == 1, most probably now > nohz.next_blocked, if > > now < nohz.next_balance, we skip the test of nr_cpus and we call > > kick_ilb() but nr_cpus == 0 and idle_cpus_mask is empty > > > >> Note we are still doing a return if nohz.nr_cpus == 0. So kick_ilb shouldn't be > >> called. > > > > The return can be skipped by if (time_before(now, nohz.next_balance)) goto out > > > > Assuming HZ=1000, > > I see LOAD_AVG_PERIOD = 32, whereas next_balance is usually 60. so it is > a really narrow window of 28 ticks and system being close to 100% busy. > > > >> > >> Do you see any path still calling kick_ilb un-necessarily? > > > > Yes but at the same time it's clearly not the main case > > > > > > So i assume we can do this patch considering the common case? > If not, let me know, I can drop it. Yes, I suppose it's ok. Could you add a comment in commit so we remember