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

Cyril Hrubis chrubis@suse.cz
Fri Dec 10 11:40:45 CET 2021


Hi!
> 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 :)

Wouldn't it be easier to rewrite these test to the C then? I think that
error handling in shell CGroup tests would always be more difficuilt
than in C and given that we have a nice library for C it actually sounds
like a better solution.

-- 
Cyril Hrubis
chrubis@suse.cz


More information about the ltp mailing list