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

[Li Wang]

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.
>>
>> Yes I agree. As I was doing the same things a few times I was beginning
> to wonder if there was a better way. I would be willing to look further into
> expanding the cgroup_lib.sh and resubmitting my recent patches with those
> changes.
>

Thanks a lot!


>
> About the compatibility of cgroup V1 and V2 in test, I'd suggest
>> following what the LTP C library did in include/tst_cgroup.h.
>>
>> https://github.com/linux-test-project/ltp/blob/master/doc/c-test-api.txt#L2024
>>
>> The solution may be briefly as:
>>
>>
>   1. scan system mounted CGroup path, and judge the situation as one of
>> below:
>>      * only CGroup V2 mounted
>>      * only CGroup V1 mounted
>>      * both CGroup V2 and V1 mounted
>>      * no CGroup mounted
>>   2. make use of the system mounted CGroup V2 or TSKIP
>>       * goto step 5
>>   3. make use of the system mounted CGroup V1
>>       * goto step 5
>>   4. do mount Cgroup as what we needed (V1 or V2) in test
>>       * goto step 5
>>   5. do cleanup
>>
>>
> Yes this would be the way to go through setting up a controller and
> checking everything.
> Going through the steps you mentioned for mounting a single controller and
> returning that path wouldn't be too hard but
> it seems to get more complicated when we want some guarantee of having
> multiple controllers in a hierarchy (if we even
> would want to support something like that, which for testing purposes
> wouldnt seem unheard of).
>

Right, it is the complicated part and you can take a reference how
the current C API handles it.

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



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



>
> or just combined them together
>
> root_mount_point = $(tst_cgroup_get_mountpoint "cpu cpuset")
>

> Again, most of the tests seem to only be testing individual controllers
> from what I can see
> so I don't know if this would be too useful. Let me know what you think.
>

Yes, the existing legacy tests based on one controller should
just work well to use the new APIs you're going to achieve.
But eventually, I think, those tests also need further refactoring
or rewriting someday.

And, the most important part is that it (CGroup shell APIs) will be
recommended to be used when a new test is written in the future,
so now it requires interfaces that have good scalability and compatibility.
No matter the test target for CGroup itself or just as an auxiliary part,
these shell APIs will play a key ingredient.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20211202/a4fd3ba1/attachment-0001.htm>