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

Luke Nowakowski-Krijger luke.nowakowskikrijger@canonical.com
Wed Dec 1 23:17:32 CET 2021


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.

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

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.


> What do you think?
>
> --
> Regards,
> Li Wang
>

Best,
- Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20211201/584ed4b2/attachment-0001.htm>


More information about the ltp mailing list