From: Wei Gao via ltp <ltp@lists.linux.it>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: "Michal Koutný" <mkoutny@suse.com>, 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: Mon, 9 Dec 2024 06:25:20 -0500 [thread overview]
Message-ID: <Z1bToBuD9yI2Whd3@wegao> (raw)
In-Reply-To: <Z1GntmAaGo_alyE0@rei.lan>
On Thu, Dec 05, 2024 at 02:16:38PM +0100, Cyril Hrubis wrote:
> 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.
Thanks all for feedback, so we can skip this patch.
>
> --
> Cyril Hrubis
> chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2024-12-09 11:25 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
2024-12-09 11:25 ` Wei Gao via ltp [this message]
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=Z1bToBuD9yI2Whd3@wegao \
--to=ltp@lists.linux.it \
--cc=chrubis@suse.cz \
--cc=mkoutny@suse.com \
--cc=wegao@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 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.