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

[Richard Palethorpe]

Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> 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

struct tst_cgroup_opts and tst_cgroup_print_config could be
extended. These are presently only used for debugging IIRC.

BTW don't worry about the purity of API too much or how it's implemented
to begin with. The current API is nice, but that is only after a lengthy
review process.

>> 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.

Perhaps, but if a test dies then we usually assume a kernel bug happened
and abort. In the future we want tests to be able to restart the system,
but we don't have concrete information about such scenarios.

>> 
>> 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.

We have to save the PID (or some kind of test ID) that is used to
identify the CGroup. So may as well save what CGroups we created as
well.

>> 
>> 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.

Yeah, I would prefer C in general. I'm not sure what is the path of
least resistance though.

-- 
Thank you,
Richard.