[LTP] [PATCH 1/4] controllers/memcg: update stress test to work under cgroup2

[Luke Nowakowski-Krijger]

Hi Richard and Li,

On Thu, Dec 2, 2021 at 1:50 AM Richard Palethorpe <rpalethorpe@suse.de>
wrote:

> Hello Li and Luke
> Li Wang <liwang@redhat.com> writes:
>
> > On Thu, Dec 2, 2021 at 6:24 AM Luke Nowakowski-Krijger <
> luke.nowakowskikrijger@canonical.com> wrote:
> >
> >  Hi Li,
> >
> >  On Wed, Dec 1, 2021 at 1:13 AM Li Wang <liwang@redhat.com> wrote:
> >
> >  Hi Luke,
> >
> >  Thanks for looking into this.
> >
> >  On Sat, Nov 27, 2021 at 8:05 AM Luke Nowakowski-Krijger <
> luke.nowakowskikrijger@canonical.com> wrote:
> >
> >  Update tests to be able to work when memory controller is mounted under
> >  cgroup2 hierarchy.
> >
> >  I'm thinking whether we could achieve these setup functions
> >  more generic in cgroup_lib.sh, which to avoid the redundancy
> >  behavior over and over again in each cgroup sub-test.
>
> +1 this is very necessary IMO
>
> Actually we can use the C API. This would avoid a whole bunch of
> issues. It requires creating a utility which we can use from shell
> (e.g. tst_cgctl).
>
> We *may* have to track state somehow. Either we could run the utility as
> a daemon initially and communicate with a socket to execute commands. Or
> we could save/serialise some state to environment/shell
> variables. Alternatively we can probably rescan the system each
> time. The only state really required is the test's PID which is needed
> to find the correct CGroup in the LTP sub-hierarchy.
>
> Still that is probably easier than dealing with all of the corner cases
> twice.
>
> I rather like this idea. If I understand you correctly we could use it in
an RPC sort of way which would make a lot of things simpler and use the
existing C API which is nice.

My one question would be if we would want this daemon to run as a test
suite utility, like it seems you are suggesting, or as a per process
utility.

The nice part of having a daemon that we could fork off for every test that
uses it would be that the cleanup / tracking of sub-groups would get
cleaned up in the normal way when we want to close the daemon and just call
tst_cgroup_cleanup(). The daemons state would be tied to the test that's
issuing commands to it. We could also send out the commands via a shared
buffer or pipe that we read and write to.

But is a daemon per test (that uses the cgroup shell api) overkill? It
seems it would spare us from having to track the test PID to sub-hierarchy
like you were mentioning. Or maybe there are some other drawbacks to the
per-test daemon idea that I'm not seeing?

Looking forward to hearing what you think.

> >
> > TBH, I even think to skip the handling on mixed mounting with V1
> > and V2, that is too messy/overthinking and not suggested using way.
> >
> > We'd better face the future and ideally as myself hoping,
> > V2 will replace V1 everywhere someday:).
>
> There are still controllers/features that don't exist on V2. Meanwhile
> there are features that only exist on V2. So if someone wants both, then
> they have to mount both. Regardless, this was the default in systemd, so
> we are stuck with it for about 20 years and can't ignore it ;-)
>
> >
> >
> >  Maybe something mimicking the tst_cgroup_require() from the C api would
> be useful here? I imagine this is where we would
> >  do the checking and mounting logic that you were describing. We would
> just also have to include checking if the controllers
> >  we are requiring can be mounted / already exist together.
> >
> >  For example I am imaging something mimicking the C api something like:
> >  tst_cgroup_require "cpu"
> >  tst_cgroup_require "cpuset"
> >  root_mount_point =$(tst_cgroup_get_mountpoint)
> >
> > I prefer this one a bit, not only it's consistent with C API but it also
> > can do CGroup mounting in tst_cgroup_require for a system without
> > V1 nor V2 mounting. Then I'd suggest having tst_cgroup_cleanup to
> > help umount that which makes things more clear to understand.
> >
> > Anyway, it depends on the details achieve, maybe there is a better
> > solution we haven't found.
>
> Yes, or if it is a utility then
>
> $ test_cpu_cg_dir = $(tst_cgroup require cpu)
> $ test_cpu_cg_dir = $(tst_cgroup require memory)
>
> maybe with an option to pass the PID to indetify the test. I guess there
> might be some existing env variable the shell API sets we could use as
> well.
>
> $ tst_cgroup cleanup --pid $MAIN_PID
>
> --
> Thank you,
> Richard.
>

 Thanks,
- Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20211202/cda42ef8/attachment-0001.htm>