From: Shashank Balaji <shashank.mahadasyam@sony.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
Shuah Khan <shuah@kernel.org>,
cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org,
Shinya Takumi <shinya.takumi@sony.com>
Subject: Re: [PATCH v2] selftests/cgroup: improve the accuracy of cpu.max tests
Date: Fri, 4 Jul 2025 15:49:58 +0900 [thread overview]
Message-ID: <aGd5lrUvm9Bhh-b8@JPC00244420> (raw)
In-Reply-To: <aGcf0Prl-hVX2j4Q@JPC00244420>
On Fri, Jul 04, 2025 at 09:26:56AM +0900, Shashank Balaji wrote:
> > > tools/testing/selftests/cgroup/test_cpu.c | 63 ++++++++++++++++-------
> > > 1 file changed, 43 insertions(+), 20 deletions(-)
> >
> >
> > > - user_usec = cg_read_key_long(cpucg, "cpu.stat", "user_usec");
> > > - if (user_usec <= 0)
> > > + if (usage_usec <= 0)
> > > goto cleanup;
> > >
> > > - if (user_usec >= expected_usage_usec)
> > > - goto cleanup;
> >
> > I think this was a meaningful check. Not sure if dropped accidentally or
> > on purpose w/out explanation.
> >
> > After that's addressed, feel free to add
> > Acked-by: Michal Koutný <mkoutny@suse.com>
>
> Sorry about that. I dropped it accidentally. This check should be okay,
> right?
>
> if (usage_usec > expected_usage_usec)
> goto cleanup;
>
> 1. We don't need to separately check user_usec because it'll always be
> less than user_usec, and usage_usec is what's directly affected by
> throttling.
> 2. I changed the >= to > because, not that it'll ever happen, but we can
> let usage_usec = expected_usage_usec pass. Afterall, it's called
> "expected" for a reason.
Hmm, here is something interesting. The following patch adds printfs to the
existing code to see what user_usec, usage_usec, the expected_usage_usec used in
the code, and the theoretical expected_usage_usec are. On running the modified test
a couple of times, here is the output:
$ sudo ./test_cpu
user: 10485, usage: 10485, used expected: 1000000, theoretical expected: 10000
ok 1 test_cpucg_max
user: 11127, usage: 11127, used expected: 1000000, theoretical expected: 10000
ok 2 test_cpucg_max_nested
$ sudo ./test_cpu
user: 10286, usage: 10286, used expected: 1000000, theoretical expected: 10000
ok 1 test_cpucg_max
user: 10404, usage: 11271, used expected: 1000000, theoretical expected: 10000
ok 2 test_cpucg_max_nested
$ sudo ./test_cpu
user: 10490, usage: 10490, used expected: 1000000, theoretical expected: 10000
ok 1 test_cpucg_max
user: 9326, usage: 9326, used expected: 1000000, theoretical expected: 10000
ok 2 test_cpucg_max_nested
$ sudo ./test_cpu
user: 10368, usage: 10368, used expected: 1000000, theoretical expected: 10000
ok 1 test_cpucg_max
user: 10026, usage: 10026, used expected: 1000000, theoretical expected: 10000
ok 2 test_cpucg_max_nested
$ sudo ./test_cpu
user: 10541, usage: 10541, used expected: 1000000, theoretical expected: 10000
ok 1 test_cpucg_max
user: 11040, usage: 11040, used expected: 1000000, theoretical expected: 10000
ok 2 test_cpucg_max_nested
So, both user_usec and usage_usec exceeding the theoretical expected_usage_usec
is not uncommon. The "fail if usage_usec >= expected_usage_usec" check in the
existing code only really works because of the (wrong) large expected_usage_usec
used.
So I think the best we can do is check if usage_usec is close to expected_usage_usec
or not, and not require usage_usec to be less than expected_usage_usec.
diff --git i/tools/testing/selftests/cgroup/test_cpu.c w/tools/testing/selftests/cgroup/test_cpu.c
index a2b50af8e9ee..14c8c7b49214 100644
--- i/tools/testing/selftests/cgroup/test_cpu.c
+++ w/tools/testing/selftests/cgroup/test_cpu.c
@@ -679,6 +679,9 @@ static int test_cpucg_max(const char *root)
if (user_usec >= expected_usage_usec)
goto cleanup;
+ printf("user: %ld, usage: %ld, used expected: %ld, theoretical expected: 10000\n",
+ user_usec, usage_usec, expected_usage_usec);
+
if (values_close(usage_usec, expected_usage_usec, 95))
goto cleanup;
@@ -739,6 +742,9 @@ static int test_cpucg_max_nested(const char *root)
if (user_usec >= expected_usage_usec)
goto cleanup;
+ printf("user: %ld, usage: %ld, used expected: %ld, theoretical expected: 10000\n",
+ user_usec, usage_usec, expected_usage_usec);
+
if (values_close(usage_usec, expected_usage_usec, 95))
goto cleanup;
@@ -758,13 +764,13 @@ struct cpucg_test {
int (*fn)(const char *root);
const char *name;
} tests[] = {
- T(test_cpucg_subtree_control),
- T(test_cpucg_stats),
- T(test_cpucg_nice),
- T(test_cpucg_weight_overprovisioned),
- T(test_cpucg_weight_underprovisioned),
- T(test_cpucg_nested_weight_overprovisioned),
- T(test_cpucg_nested_weight_underprovisioned),
+ // T(test_cpucg_subtree_control),
+ // T(test_cpucg_stats),
+ // T(test_cpucg_nice),
+ // T(test_cpucg_weight_overprovisioned),
+ // T(test_cpucg_weight_underprovisioned),
+ // T(test_cpucg_nested_weight_overprovisioned),
+ // T(test_cpucg_nested_weight_underprovisioned),
T(test_cpucg_max),
T(test_cpucg_max_nested),
};
next prev parent reply other threads:[~2025-07-04 6:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 14:13 [PATCH 0/2] selftests/cgroup: better bound for cpu.max tests Shashank Balaji
2025-07-01 14:13 ` [PATCH 1/2] selftests/cgroup: rename `expected` to `duration` in " Shashank Balaji
2025-07-01 14:13 ` [PATCH 2/2] selftests/cgroup: better bound " Shashank Balaji
2025-07-02 12:34 ` [PATCH 0/2] selftests/cgroup: better bound for " Michal Koutný
2025-07-03 1:41 ` Shashank Balaji
2025-07-03 8:54 ` Michal Koutný
2025-07-03 12:03 ` [PATCH v2] selftests/cgroup: improve the accuracy of " Shashank Balaji
2025-07-03 15:58 ` Michal Koutný
2025-07-04 0:26 ` Shashank Balaji
2025-07-04 6:49 ` Shashank Balaji [this message]
2025-07-04 8:59 ` Michal Koutný
2025-07-04 9:07 ` Shashank Balaji
2025-07-04 9:15 ` Shashank Balaji
2025-07-04 9:41 ` Michal Koutný
2025-07-04 11:08 ` [PATCH v3] selftests/cgroup: fix " Shashank Balaji
2025-07-11 0:21 ` Shashank Balaji
2025-07-17 18:12 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aGd5lrUvm9Bhh-b8@JPC00244420 \
--to=shashank.mahadasyam@sony.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=shinya.takumi@sony.com \
--cc=shuah@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.