linux-kernel - Re: [PATCH] sched/cgroup: Lock optimize for cgroup cpu throttle

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20250811151316.838707-1-jackzxcui1989@163.com>
Date: Mon, 11 Aug 2025 23:13:16 +0800
From: Xin Zhao <jackzxcui1989@....com>
To: tj@...nel.org,
	hannes@...xchg.org,
	mkoutny@...e.com,
	mingo@...hat.com,
	peterz@...radead.org,
	juri.lelli@...hat.com,
	vincent.guittot@...aro.org,
	dietmar.eggemann@....com,
	rostedt@...dmis.org,
	bsegall@...gle.com,
	mgorman@...e.de,
	vschneid@...hat.com,
	will@...nel.org,
	boqun.feng@...il.com,
	longman@...hat.com,
	bigeasy@...utronix.de,
	clrkwllms@...nel.org
Cc: cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH] sched/cgroup: Lock optimize for cgroup cpu throttle

On Mon, 2025-08-11 at 16:36 +0800, Sebastian wrote:

> What about using task_work_add() and throttling the task on its way to
> userland? The callback will be invoked without any locks held.

Dear Sebastian,

I believe what you mentioned is related to the same issue that Valentin
brought up later, which is the current solution of "delaying CPU throttling
through the task_work mechanism until returning to user mode."
My colleagues and I indeed noticed this from the beginning. However, on our
6.1.134 RT-Linux system, we have tried new versions of this solution one by
one, but they have all failed during basic script tests, so none have reached
the stage of being used in our project. I see that this modification has been
promoted in the community for more than two years, yet it remains in a state
that doesn't work well (on our 6.1.134 RT-Linux system). I wonder if the
changes require too many considerations or if this modification simply isn't
suitable for running on RT-Linux. Our project cannot afford to wait, and
there are many performance issues in RT-Linux.
Therefore, I focused on making minimal changes to a complex and stable
scheduling system (at least not altering the complex management logic of
nr_running and related logic) and instead worked on the code of lock module
and the logic of adjusting priorities, which are relatively easier to
understand and modify.
As a result, I implemented a patch that runs stably on 6.1.134 RT-Linux and
meets the demands.

Thanks
Xin Zhao