linux-kernel - Re: [RFC PATCH] cgroup: Track time in cgroup v2 freezer

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: <aF7qjAkwXhjTVmT-@slm.duckdns.org>
Date: Fri, 27 Jun 2025 09:01:32 -1000
From: Tejun Heo <tj@...nel.org>
To: Tiffany Yang <ynaffit@...gle.com>
Cc: linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	kernel-team@...roid.com, John Stultz <jstultz@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Stephen Boyd <sboyd@...nel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	Frederic Weisbecker <frederic@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Koutný <mkoutny@...e.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Pavel Machek <pavel@...nel.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Chen Ridong <chenridong@...wei.com>, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.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>
Subject: Re: [RFC PATCH] cgroup: Track time in cgroup v2 freezer

Hello,

On Thu, Jun 26, 2025 at 07:19:18PM -0700, Tiffany Yang wrote:
...
> Fortunately, since this same latency is present when we
> unfreeze a cgroup and each member task, it's effectively canceled out
> when we look at the freezing duration for tasks in cgroups that are not
> currently frozen. For a running task, the measurement of how long it had
> spent frozen in the past was within 1-2 ticks of its cgroup's. Our use
> case does not look at this accounting until after a task has become
> unfrozen, so the per-cgroup values seem like a reasonable substitution
> for our purposes!

Glad that worked out, but I'm curious what are the involved time scales.
Let's say you get things off by some tens of msecs, or maybe even hundreds,
does that matter for your purpose?

> That being said, I realized from Michal's reply that the tracked value
> doesn't have to be as narrow as the cgroup v2 freezing time. Basically,
> we just want to give userspace some measure of time that a task cannot
> run when it expects to be running. It doesn't seem practical to give an
> exact accounting, but maybe tracking the time that each task spends in
> some combination of stopped or frozen would provide a useful estimate.

While it's not my call, I'm not necessarily against. However, as you noted
in another reply, the challenge is that there are multiple states and it's
not clear what combinations would be useful for whom. When/if we encounter
more real world use cases tha twould require these numbers, they may shed
light on what the right combination / interface is. IOW, I'm not sure this
is a case where adding something preemptively is a good idea.

Thanks.

-- 
tejun