<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><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>
>> > As I was mentioned in 0/5 that maybe we should create test_cgroup_dir<br>
>> > for different progress so that the test could use the same controller<br>
>> with<br>
>> > various configurations in parallel.<br>
>> ><br>
>> > e.g. child_1 set SIZE to memory.limit_in_bytes<br>
>> > child_2 set SIZE/2 to memory.limit_in_bytes<br>
>> ><br>
>> > Any possibility to move this to tst_cgroup_move_current?<br>
>><br>
>> Yes I suppose we can try this. Is there a test which already requires it?<br>
>><br>
><br>
> So far we don't have such a test, I remember that in the previous Lib is<br>
> also to keep expandability.<br>
<br>
I think we have at least two problems:<br>
<br>
1) This allows many CGroups to be created for each test and we must<br>
clean them up, adding some complication.<br>
<br>
2) It's not clear if a future test will require the CGroup hierarchy to<br>
be the same as the process hierarchy or different. Depending what<br>
behaviour for tst_cgroup_move_current we choose it will make some<br>
configurations impossible.<br>
<br>
So if we add this then it will add complexity, but I am not sure it will<br>
help in the future. If we make it flexible enough to support any<br>
hierarchy this will add a lot of complication.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Okay. I do NOT insist to implement a future feature at this early</div><div class="gmail_default" style="font-size:small">moment, but do u think we'd better mention this in documents? </div><div class="gmail_default" style="font-size:small">To let people(avoid abusing it) know that the current CGroup lib</div><div class="gmail_default" style="font-size:small">hasn't supported children using the same controller in parallel?</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And another new query is, do we really need to export many</div><div class="gmail_default" style="font-size:small">cleanup-levels to users? I guess we can handle it in the library</div><div class="gmail_default" style="font-size:small">with intelligently choose levels no matter in parallel or sequential.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">i.e. As now only one directory(test-pid/) created for one test in a</div><div class="gmail_default" style="font-size:small">hierarchy, how about going with TST_CGROUP_CLEANUP_ROOT</div><div class="gmail_default" style="font-size:small">level by default, unless it detects more or equal to two directories</div><div class="gmail_default" style="font-size:small">(that probably means parallel) goes TST_CGROUP_CLEANUP_TEST?</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>
Also if we did need this feature in the future, then we can add some new<br>
functions which take a sub-group (or hierarchy) parameter. e.g.<br>
<br>
void tst_cgroup_move(enum tst_cgroup_ctrl type, pid_t pid,<br>
struct tst_cgroup_tree *path);<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Sounds good to me.</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>
Alternate versions of other functions would also need to be added. Also<br>
some changes to the internal data structures may be needed. However it<br>
would keep the current API functions simple.<br>
<br>
So until we have a test which requires this, I think the best option is<br>
to do nothing :-)<br>
<br>
-- <br>
Thank you,<br>
Richard.<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>