linux-kernel - Re: [RESEND RFC PATCH v2 28/29] [EXPERIMENTAL] sched/fair: Add a local counter to rate limit task push

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6236b897-8924-4065-9193-30f8fd2dfda5@amd.com>
Date: Mon, 8 Dec 2025 23:05:25 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Christian Loehle <christian.loehle@....com>, Ingo Molnar
	<mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Juri Lelli
	<juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>, Frederic Weisbecker
	<frederic@...nel.org>, Thomas Gleixner <tglx@...utronix.de>
CC: <linux-kernel@...r.kernel.org>, Dietmar Eggemann
	<dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall
	<bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Valentin Schneider
	<vschneid@...hat.com>, "Gautham R. Shenoy" <gautham.shenoy@....com>, "Swapnil
 Sapkal" <swapnil.sapkal@....com>, Shrikanth Hegde <sshegde@...ux.ibm.com>,
	Chen Yu <yu.c.chen@...el.com>
Subject: Re: [RESEND RFC PATCH v2 28/29] [EXPERIMENTAL] sched/fair: Add a
 local counter to rate limit task push

Hello Chris,

On 12/8/2025 6:03 PM, Christian Loehle wrote:
> Just to confirm, but this patch is included when the cover letter mentions "push" for the
> benchmarks?

Yes, this patch is included.

> Did this help the regressions then?

So without this, I was just using tbench as a smoke test - server client
pair sending a very small amount of data and can lead to very short sleep
time.

Up till 64 client there were slight improvements from not rate limiting
but once I hit the fully loaded case, tbench regresses by up to 10%
mostly because of lack of idle targets but also the CPU doesn't hit the
overutilized threshold to cancel push attempts.

CPUs are still considered "nohz" until the first tick hits and at a high
frequency of CPUs going in and out of idle, "sd->shared->nr_idle_cpus"
turned unreliable in my case as a bailout threshold,

With this rate limiting, things are within 2-3% of the baseline.

-- 
Thanks and Regards,
Prateek