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

[Luke Nowakowski-Krijger]

Hi Richard and Li,

On Mon, Dec 6, 2021 at 1:24 AM Richard Palethorpe <rpalethorpe@suse.de>
wrote:

> I suppose we also need to remember if the current test created the ltp
> subdirectory or mounted any controllers.
>
>
We could do this by just printing the required command line options to
> stdout when the utility exits. Then save this to a variable for the next
> use.
>
>

Yes, we would have to remember what we mounted. I think the part I am most
curious about is how we would generate that state i.e what we mounted,
because the Cgroup library does not expose any of this as far as I'm aware.

If we want to use the tst_cgroup C lib to cleanup as well we would have to
find a way to reintroduce test state to the lib that we are losing between
calls of the utility, which the only way I could think of is introducing a
way to export and import test state within the lib. e.g.
tst_cgroup_print_test_state() tst_cgroup_load_test_state(), which doesn't
feel good as it exposes some of the nice API you have going on. This is the
easiest way to tell if we are mounting things because we can just print
what we mounted, what the test dir of the test is, and reload that state.
This could have further applications to not just this scenario but also to
scenarios where if a test dies its state can be reloaded, etc, almost in a
checkpoint way. Not saying its common but adds some flexibility to the API
and I could see it having applications outside of this utility.

Alternatively we could inspect what we created and generate state that way,
i.e. make a call to tst_cgroup_require() and see if new things were
mounted. Then we would have to manually be freeing things. I don't like
this approach because it goes against the whole point of this which was
code reuse. But the cleanup of things isnt the most difficult part so it
wouldn't be the biggest deal to redo the logic.

Yes, sounds good.
>
>
Let me know what you think. I wouldn't want to add anything huge to the API
without your blessing :)

> --
> Thank you,
> Richard.
>

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