From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (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 393971DDC35 for ; Tue, 5 Aug 2025 03:29:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754364598; cv=none; b=cTcEZzgqOr9n5nn0Ooe+Ry+mdaEt43mGAFCUONfkWm/ok0reOrNfZZ6z534ABg/AvWNIyzgzkTaqXt4ivIXeL+ap4w0AOxT636CGSo7Pmdkcjmb/TSWmvsstR5XqAOoU6BuF2WkMhWtLMsoT6QrWjeTPBpeRucphEK9pa07e4ak= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754364598; c=relaxed/simple; bh=hKNey2M65NfB1i5iWVZHmHR4W8oYtDhF8YeJMlTTAUc=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=Y4T1pJKWfEE9zf4hVeiKFMY9Oxt6gapjasPSyBxySrFcI3GlWMZn3G6O8e/KikTxpQVZkl257SDtCuzY1EORESOVUsQ8EVGOontJnSooNtlrpDy/PMgNPt7Cm4ymKyFPU2GmlsUzNbm/cqSqE/xmc2BsIOFHiBSZTqmZ1wTrUiM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--ynaffit.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=iDJ9cTlm; arc=none smtp.client-ip=209.85.210.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--ynaffit.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iDJ9cTlm" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-74d15d90cdbso3699143b3a.0 for ; Mon, 04 Aug 2025 20:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1754364596; x=1754969396; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=O4e9hLBnrm2iVH1X9AV4+u69aPgdnAgGMzmvdOS5R1s=; b=iDJ9cTlmtLLZlk96Z6o3SMkkhhT+x8Es2Guvx3p9d6/VyR2zNdrGn3pzE/LK8RO8zK T+18oP6d2FZFAei+Sd6Nr8nKsd7qic29lNDpiGCYm3zUQQ9L2NMEGLy9fgzsWywq6d+s 0F4+AUNDmJsi5DJmrBdm9dPrIJjm/IeHFAaJxFfo3rlyJOjmoEv/CVPcf+5ml9J3G1zP jNagTz0k7+ChsrbnDUolFVx7sPWWYDaXU/t1WXhiANq0917USerWnrEhnnAMaT6tsU/V lxTjiZxkCni7PeAO+/wDuHKkbso/VW0sccU7X5wGiRunZu1PuJ/tqldV4GoYcz3WNWT9 +DWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754364596; x=1754969396; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=O4e9hLBnrm2iVH1X9AV4+u69aPgdnAgGMzmvdOS5R1s=; b=bnh8/XmcmEiLo5NA/nqDVFdwN4wYFUtW6DctuFCBk7fdqHsSgL/I+vrXymQagxIgzk s/J4859yHH/ChvLkyRXyUpHW+/6g5sidACigg+QLdk7TTLeESCgBZYYFoIFo2UZkmteG 7LeVDcNo8KZBXIESITIJJC9TAAxSLtM+ilMC2HBdC67iw/NGDNle/QwLMyGcG0rsbixX caUPCfCgwfKSM9P0WycaxHagxaRgHPDX69NELtYMoD82YNNSgqL6oOcJ0U+Rw13G7c3i YsrKHSDLEY2Jlc7LadCCV2dG9fyJNTywPgKwlGTR5hrQEv9TTUtjTNKlinx0WZ0WDo35 BV1A== X-Gm-Message-State: AOJu0YzQPzxijnHnfoLgkTwXFzK2aJVRlleRlKBuXHIVFkCuf4JXt9Kg IJUtFB6stHSCb6t+n+zcgC2yIq9/Zfj9X7Pe5ZnMX1aIO0QnAWVPSfn7LGVgn/83qbx/4GSHLK7 s6jcLWc/L4wQ9rP5aZ7da7aMwxl4NEKmYxKlVf2vWngJ4sBCGoJfE1ItIHjG6h2/nthm9Skw6cy 6CJbaB+b505Iec6uEtbPHCV4pDIvgZ3Qt6AtqeosdK0XtjuMv8Nw== X-Google-Smtp-Source: AGHT+IHCQb17vXlV4e52P4N0dmYJzN1VGo2n3q5QjSHbjsj9Nn7wVegPuuz3ngnDNMTzTldH9NHl9VVaoIFp X-Received: from pfbcd26.prod.google.com ([2002:a05:6a00:421a:b0:748:ec4d:30ec]) (user=ynaffit job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1495:b0:74c:efae:ffae with SMTP id d2e1a72fcca58-76bec2fca4bmr15187096b3a.5.1754364596278; Mon, 04 Aug 2025 20:29:56 -0700 (PDT) Date: Mon, 4 Aug 2025 20:29:40 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.50.1.565.gc32cd1483b-goog Message-ID: <20250805032940.3587891-4-ynaffit@google.com> Subject: [RFC PATCH v3 0/2] cgroup: Track time in cgroup v2 freezer From: Tiffany Yang To: linux-kernel@vger.kernel.org Cc: John Stultz , Thomas Gleixner , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Tejun Heo , Johannes Weiner , "=?UTF-8?q?Michal=20Koutn=C3=BD?=" , "Rafael J. Wysocki" , Pavel Machek , Roman Gushchin , Chen Ridong , kernel-team@android.com, Jonathan Corbet , Shuah Khan , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="true" Content-Transfer-Encoding: quoted-printable 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 --- v3: * Use seqcount along with css_set_lock to guard freeze time accesses as suggested by Michal Koutn=C3=BD * Add selftests v2: https://lore.kernel.org/lkml/20250714050008.2167786-2-ynaffit@google.co= m/ * 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.co= m/ Cc: John Stultz Cc: Thomas Gleixner Cc: Stephen Boyd Cc: Anna-Maria Behnsen Cc: Frederic Weisbecker Cc: Tejun Heo Cc: Johannes Weiner Cc: Michal Koutn=C3=BD Cc: "Rafael J. Wysocki" Cc: Pavel Machek Cc: Roman Gushchin Cc: Chen Ridong 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(-) --=20 2.50.1.565.gc32cd1483b-goog