<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Richard,</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de" target="_blank">rpalethorpe@suse.de</a>> wrote:<br></div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-size:small">...</span><br>
<br>
Well, I have learnt some more about CGroups and reviewed some of our<br>
tests which use them and am now considering the following. This is so<br>
complicated that the below will probably turn out to be wrong as I try<br>
to implement it.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Glad to see your improvement plan.</div></div><div class="gmail_default" style="font-size:small"><br></div><div><div class="gmail_default" style="font-size:small">It's okay, we can try it in practice. Sometimes the perfect solution</div><div class="gmail_default" style="font-size:small">will be born in the code <span style="color:rgb(51,51,51);font-size:14px">iteration :).</span></div></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">
<br>
1) Scan the system for mounted Cgroup controllers and create a data<br>
structure describing what controllers are mounted and where.<br>
<br>
There is only one cgroup root, it is possible to mount it multiple<br>
times, but it simplifies matters if we try to reuse whatever is already<br>
mounted. Especially in the case of V1 where remounting with different<br>
controller combinations will fail. Possibly there is some advantage to<br>
remounting, but I can't see what because changes to one mount are likely<br>
to be reflected in others, plus remounting is likely to fail if you<br>
don't use the same mount options.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I doubt that will be simplified to reuse the existing CGroup, It</div><div class="gmail_default" style="font-size:small">sounds a bit idealization. Since there might be different paths</div><div class="gmail_default" style="font-size:small">mounted on their Linux distributions or self-customized system,</div><div class="gmail_default" style="font-size:small">we have to cover/scan all unsure situations if go this way, isn't it?</div></div><div class="gmail_default" style="font-size:small"> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2) The user requests some controller values to be set in a unified<br>
hierarchy. The LTP library then tries to translate this to whatever<br>
CGroup setup the system is actually using.<br>
<br>
If no cgroups are mounted, then we try to mount a simple V2 setup<br>
falling back to the standard V1 setup with the (required) controllers in<br>
separate hierarchies. For some tests this will result in a hybrid setup<br>
because they first request a V2 compatible controller then a V1 only<br>
controller (or the inverse if there are any V2 only controllers). At<br>
least SUSE and Ubuntu are using hybrid setups so this is a valid thing<br>
to test (unfortunately).<br></blockquote><div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">+1</div></div><div><div class="gmail_default" style="font-size:small">Yes, I totally agree to handle this kind of issue, which currently</div><div class="gmail_default" style="font-size:small">LTP-CGroup-Lib has not done it. This is the new progress for us.</div></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">
<br>
If we find mounted controllers then try to create a new LTP hierarchy in<br>
the root of each controller (on V2 all the controllers are mounted to<br>
the same place, but V1 allows all kinds of stuff).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That sounds too complicated, there would be a situation that partly</div><div class="gmail_default" style="font-size:small">used V2 in the root CGroup and also to use the V1-only controller</div><div class="gmail_default" style="font-size:small">in a newly mounted V1 hierarchy. </div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default">Another concern is about the cleanup work, I'm not sure this will</div><div class="gmail_default">be more simple or needs unify way to remove all created dir in the</div><div class="gmail_default">hierarchy for both V2 and V1 mixed.</div><div class="gmail_default"><br></div><div class="gmail_default">And, it is probably much difficult for debugging if hitting some problems.</div></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">
<br>
3) The user requests some process is moved to a node of the unified<br>
hierarchy for one or more controllers.<br>
<br>
Do the same setup as 2) if necessary. For V2 setups or V1 setups where<br>
all the controllers are mounted to the same place the controller<br>
argument is ignored. It is only relevant for V1 setups with separate<br>
hierarchies for some of the controllers. Of course a version of the<br>
interface can be provided without the controller argument.<br>
<br>
4) The user requests processes are removed from our hierarchy (back to<br>
root) and/or we destroy our hierarchy.<br>
<br>
If we mounted any controllers unmount them, otherwise we just drain our<br>
hierarchy and remove it. Some tests currently just move their process<br>
into a cgroup (on each iteration instead of in setup) and never out of<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Right, but at least, all of the processes will be kick-out from CGroup</div><div class="gmail_default" style="font-size:small">hierarchy before unmounting in the cleanup phase.</div></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">
it. I don't think this makes sense, so that is another thing to<br>
investigate.<br>
<br>
I think the above will work for tests which are simply trying to use<br>
CGroup features even on systems which have an unusual V1 setup (but not<br>
all V1 setups). For tests which are trying to test CGroups themselves,<br>
then we will have to look at each test case and figure out if any code<br>
can be shared.<br>
<br>
For some tests (e.g. madvise06) we can provide a declarative interface<br>
like:<br>
<br>
tst_test.cgroup = {<br>
{"memory", "max", 256MB},<br>
{"memory", "swappiness", 60},<br>
{ NULL },<br>
};<br>
<br>
Then the library will create a cgroup, set the memory controllers limit<br>
and put the test process in the cgroup. However a more thorough review<br>
of our cgroup usage is needed before deciding on a declarative<br>
interface.<br>
<br>
Note that so far I have not seen a need to create complex hierarchies<br>
for our tests or use threaded V2 controllers, but we will need to do<br>
this to test cgroups themselves. However most tests just need some basic<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">+1</div><div class="gmail_default" style="font-size:small">That's also a long term goal for LTP and I had left open interfaces for the</div><div class="gmail_default" style="font-size:small">purpose of extending and further development work.</div></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">
cgroup features and we can use test variants to enable random cgroup<br>
features on any test or implement cgroups in the test runner.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Good point.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Btw, I think you can try the thoughts first, as you mentioned it is</div><div class="gmail_default" style="font-size:small">too complicated so we can't finish everything just in one time.</div><div class="gmail_default" style="font-size:small">But the better solution will be fine out in practice I believe.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Here is the previous discussion about cover different CGroup <span style="color:rgb(0,0,0);white-space:pre-wrap">scenarios</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);white-space:pre-wrap">supporting(the end part of email)</span>, FYI:</div><div class="gmail_default" style="font-size:small"><a href="http://lists.linux.it/pipermail/ltp/2020-June/017442.html">http://lists.linux.it/pipermail/ltp/2020-June/017442.html</a><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>