<div dir="ltr"><div>Hi Li, <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 1, 2021 at 1:13 AM Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-size:small">Hi Luke,</div></div><div><br></div><div><div style="font-size:small">Thanks for looking into this.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 27, 2021 at 8:05 AM Luke Nowakowski-Krijger <<a href="mailto:luke.nowakowskikrijger@canonical.com" target="_blank">luke.nowakowskikrijger@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Update tests to be able to work when memory controller is mounted under<br>
cgroup2 hierarchy.<br></blockquote><div><br></div><div><div style="font-size:small">I'm thinking whether we could achieve these setup functions</div><div style="font-size:small">more generic in cgroup_lib.sh, which to avoid the redundancy</div><div style="font-size:small">behavior over and over again in each cgroup sub-test.</div><br></div></div></div></blockquote><div>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</div><div>expanding the cgroup_lib.sh and resubmitting my recent patches with those changes. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div><div style="font-size:small">About the compatibility of cgroup V1 and V2 in test, I'd suggest</div><div style="font-size:small">following what the LTP C library did in include/tst_cgroup.h.</div><div style="font-size:small"><a href="https://github.com/linux-test-project/ltp/blob/master/doc/c-test-api.txt#L2024" target="_blank">https://github.com/linux-test-project/ltp/blob/master/doc/c-test-api.txt#L2024</a></div><br></div><div><div style="font-size:small">The solution may be briefly as:</div></div><div> </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div style="font-size:small"></div><div><div style="font-size:small"> 1. scan system mounted CGroup path, and judge the situation as one of below:</div><div style="font-size:small"> * only CGroup V2 mounted</div><div style="font-size:small"> * only CGroup V1 mounted</div><div style="font-size:small"> * both CGroup V2 and V1 mounted</div><div style="font-size:small"> * no CGroup mounted</div><div style="font-size:small"> 2. make use of the system mounted CGroup V2 or TSKIP</div><div style="font-size:small"> * goto step 5</div><div style="font-size:small"> 3. make use of the system mounted CGroup V1 </div><div style="font-size:small"> * goto step 5</div><div style="font-size:small"> 4. do mount Cgroup as what we needed (V1 or V2) in test</div></div><div style="font-size:small"> * goto step 5<br></div><div style="font-size:small"> 5. do cleanup </div><div><br></div></div></div></blockquote><div><br></div><div>Yes this would be the way to go through setting up a controller and checking everything. <div>Going through the steps you mentioned for mounting a single controller and returning that path wouldn't be too hard but <br></div><div>it seems to get more complicated when we want some guarantee of having multiple controllers in a hierarchy (if we even</div><div>would want to support something like that, which for testing purposes wouldnt seem unheard of).<br> </div>Maybe something mimicking the tst_cgroup_require() from the C api would be useful here? I imagine this is where we would</div><div>do the checking and mounting logic that you were describing. We would just also have to include checking if the controllers</div><div>we are requiring can be mounted / already exist together.<br></div><div><br></div><div>For example I am imaging something mimicking the C api something like:</div><div>tst_cgroup_require "cpu"</div><div>tst_cgroup_require "cpuset"</div><div>root_mount_point =$(tst_cgroup_get_mountpoint)</div><div><br></div><div>or just combined them together<br></div><div><br></div><div>root_mount_point = $(tst_cgroup_get_mountpoint "cpu cpuset")</div><div><br></div><div>Again, most of the tests seem to only be testing individual controllers from what I can see</div><div>so I don't know if this would be too useful. Let me know what you think.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div><div style="font-size:small">What do you think?</div></div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div></blockquote><div><br></div><div>Best, <br></div><div>- Luke<br></div></div></div>