From: Cyril Hrubis <chrubis@suse.cz>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v1] tst_cgroup.c: Force tst_cg_scan only scan specific cgroup version if needs_ver exist
Date: Thu, 5 Dec 2024 14:16:38 +0100 [thread overview]
Message-ID: <Z1GntmAaGo_alyE0@rei.lan> (raw)
In-Reply-To: <dnhjiv6iqwbref6kaq2amylqbwrksnph3l7ewxgqetp6crrz3s@3k5j5t4sy2gl>
Hi!
> > You are supposed to get an error here, at least that is what I thought.
>
> That depends -- if the controller's tasks are all in its (only) root
> cgroup, it can be re-bind between hierarchies (v1 to v2 or vice versa).
>
> > I do get error here on vanilla 6.10 but on debian 6.1 the mount succeeds
> > as well. CCing Michal.
>
> If /sys/fs/cgroup/cgroup.subtree_control contains `cpuset`, it's likely
> used by some of the services, hence not all tasks are in the root cgroup
> and re-binding fails. That's what can differ between systems.
>
> > Michal I was under an impression that a controller that has been bound
> > to v2 cannot be removed from there and bound to v1 anymore, but it seems
> > that it may happen in some cases.
>
> It can happen under the condition above.
> (And in a future kernel it may be truly unavailable in v1 with
> !CONFIG_CPUSETS_V1.)
Thanks for the clarifications.
I still do not think that re-binding controllers to v1 is a good idea
though. Firstly v1 is being phased out and we will eventually get rid
of it, so there is no point in investing too much effort into v1 testing
in hybrid environments.
And secondly I fear that we may end up skipping v2 tests because of the
rebinding. What I think may happen is that the cgroup cleanup is
asynchronous which means that there still would be remnants of the v1
cpuset cgroup even after the particular v1 test would exit, which would
cause next test a v2 test to be skipped, because the rebinding would
fail.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-12-05 13:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 5:37 [LTP] [PATCH v1] tst_cgroup.c: Force tst_cg_scan only scan specific cgroup version if needs_ver exist Wei Gao via ltp
2024-11-08 9:53 ` Cyril Hrubis
2024-11-08 11:21 ` Wei Gao via ltp
2024-11-08 11:23 ` Cyril Hrubis
2024-11-11 2:47 ` Wei Gao via ltp
2024-11-11 12:08 ` Cyril Hrubis
[not found] ` <dnhjiv6iqwbref6kaq2amylqbwrksnph3l7ewxgqetp6crrz3s@3k5j5t4sy2gl>
2024-12-05 13:16 ` Cyril Hrubis [this message]
2024-12-09 11:25 ` Wei Gao via ltp
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=Z1GntmAaGo_alyE0@rei.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=mkoutny@suse.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox