Hello,
The cgroup v2 freezer controller is useful for freezing background applications so they don't contend with foreground tasks. However, this may disrupt any internal monitoring that the application is performing, as it may not be aware that it was frozen.
To illustrate, an application might implement a watchdog thread to monitor a high-priority task by periodically checking its state to ensure progress. The challenge is that the task only advances when the application is running, but watchdog timers are set relative to system time, not app time. If the app is frozen and misses the expected deadline, the watchdog, unaware of this pause, may kill a healthy process.
This series tracks the time that each cgroup spends "freezing" and exposes it via cgroup.freeze.stat.local. If others prefer, I can instead create cgroup.stat.local and allow the freeze time accounting to be accessed there instead.
This version includes several basic selftests. I would find feedback especially useful here! Along with testing basic functionality, I wanted to demonstrate the following relationships: 1. Freeze time will increase while a cgroup is freezing, regardless of whether it is frozen or not. 2. Each cgroup's freeze time is independent from the other cgroups in its hierarchy.
I was hoping to show (1.) with a test that freezes a cgroup and then checks its freeze time while cgroup.events still shows "frozen 0", but I am having trouble writing a case that can reliably cause this (even when letting a forkbomb grow for a while before attempting to freeze!). Ideally, I could populate a test cgroup with an unfreezable task. Is there an elegant way to create a process from a selftest that will become TASK_INTERRUPTIBLE?
The main challenge in establishing (2.) is that in order to make a meaningful comparison between two cgroups' freeze times, they need to be obtained at around the same time. The test process may check one cgroup's freeze time, but then it may be preempted and delayed from checking another cgroup's for a relatively "long" time. I have tried to use sleeps to increase what a "long" time would be, but this possibility makes tests like test_cgfreezer_time_parent non-deterministic, so I am a bit squeamish about adding it here.
Any suggestions for better tests or anything else would be welcome.
Thank you! Tiffany
Signed-off-by: Tiffany Yang ynaffit@google.com --- v3: * Use seqcount along with css_set_lock to guard freeze time accesses as suggested by Michal Koutný * Add selftests
v2: https://lore.kernel.org/lkml/20250714050008.2167786-2-ynaffit@google.com/ * Track per-cgroup freezing time instead of per-task frozen time as suggested by Tejun Heo
v1: https://lore.kernel.org/lkml/20250603224304.3198729-3-ynaffit@google.com/
Cc: John Stultz jstultz@google.com Cc: Thomas Gleixner tglx@linutronix.de Cc: Stephen Boyd sboyd@kernel.org Cc: Anna-Maria Behnsen anna-maria@linutronix.de Cc: Frederic Weisbecker frederic@kernel.org Cc: Tejun Heo tj@kernel.org Cc: Johannes Weiner hannes@cmpxchg.org Cc: Michal Koutný mkoutny@suse.com Cc: "Rafael J. Wysocki" rafael@kernel.org Cc: Pavel Machek pavel@kernel.org Cc: Roman Gushchin roman.gushchin@linux.dev Cc: Chen Ridong chenridong@huawei.com
Tiffany Yang (2): cgroup: cgroup.freeze.stat.local time accounting cgroup: selftests: Add tests for freezer time
Documentation/admin-guide/cgroup-v2.rst | 20 + include/linux/cgroup-defs.h | 17 + kernel/cgroup/cgroup.c | 28 + kernel/cgroup/freezer.c | 10 +- tools/testing/selftests/cgroup/test_freezer.c | 686 ++++++++++++++++++ 5 files changed, 759 insertions(+), 2 deletions(-)