<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Luke Nowakowski-Krijger <<a href="mailto:luke.nowakowskikrijger@canonical.com">luke.nowakowskikrijger@canonical.com</a>> wrote:</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><br></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"><br></blockquote></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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Actually we can use the C API. This would avoid a whole bunch of<br>
issues. It requires creating a utility which we can use from shell<br>
(e.g. tst_cgctl).<br></blockquote></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">+1 This is a good idea.</div><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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We *may* have to track state somehow. Either we could run the utility as<br>
a daemon initially and communicate with a socket to execute commands. Or<br>
we could save/serialise some state to environment/shell<br>
variables. Alternatively we can probably rescan the system each<br>
time. The only state really required is the test's PID which is needed<br>
to find the correct CGroup in the LTP sub-hierarchy.<br>
<br>
Still that is probably easier than dealing with all of the corner cases<br>
twice.<br>
<br></blockquote><div>I rather like this idea. If I understand you correctly we could use it in an RPC sort of way which would make a lot of things simpler and use the existing C API which is nice. <br></div><div><br></div><div>My one question would be if we would want this daemon to run as a test suite utility, like it seems you are suggesting, or as a per process utility.</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Hmm, why do we need that utility as a daemon in the background? </div><div class="gmail_default" style="font-size:small">Isn't it easier to execute a binary utility to get the CGroup path</div><div class="gmail_default" style="font-size:small">only when needed? Just like Richard mentioned the alternative</div></div><div class="gmail_default" style="font-size:small">way, rescan system each time and only distinguish correct CGroup</div><div class="gmail_default" style="font-size:small">path via the test PID.</div><div class="gmail_default" style="font-size:small"><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> <br></div><div><br></div><div>The nice part of having a daemon that we could fork off for every test that uses it would be that the cleanup / tracking of sub-groups would get cleaned up in the normal way when we want to close the daemon and just call tst_cgroup_cleanup(). The daemons state would be tied to the test that's issuing commands to it. We could also send out the commands via a shared buffer or pipe that we read and write to. <br></div><div><br></div><div>But is a daemon per test (that uses the cgroup shell api) overkill? It seems it would spare us from having to track the test PID to sub-hierarchy like you were mentioning. Or maybe there are some other drawbacks to the per-test daemon idea that I'm not seeing?<br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I think yes, starting a daemon per test is not wise.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Another drawback I can think of is that will definitely affect paralleling things,</div><div class="gmail_default" style="font-size:small"><div class="gmail_default">we must guarantee the CGroup mounted by testA shouldn't be scanned/used</div><div class="gmail_default">by testB, otherwise, it will fail in the cleanup phase. But, we can make the LTP </div><div class="gmail_default">test mounted CGroup path is transparent to others just by adding a special string</div><div class="gmail_default">like "ltp-cgroup".</div></div></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>