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

[Li Wang]

Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> wrote:

>
> Richard Palethorpe <rpalethorpe@suse.de> wrote:
>
>>
>> Actually we can use the C API. This would avoid a whole bunch of
>> issues. It requires creating a utility which we can use from shell
>> (e.g. tst_cgctl).
>>
>
+1 This is a good idea.



>
>> We *may* have to track state somehow. Either we could run the utility as
>> a daemon initially and communicate with a socket to execute commands. Or
>> we could save/serialise some state to environment/shell
>> variables. Alternatively we can probably rescan the system each
>> time. The only state really required is the test's PID which is needed
>> to find the correct CGroup in the LTP sub-hierarchy.
>>
>> Still that is probably easier than dealing with all of the corner cases
>> twice.
>>
>> 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.
>
> 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.
>

Hmm, why do we need that utility as a daemon in the background?
Isn't it easier to execute a binary utility to get the CGroup path
only when needed? Just like Richard mentioned the alternative
way, rescan system each time and only distinguish correct CGroup
path via the test PID.



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

I think yes, starting a daemon per test is not wise.

Another drawback I can think of is that will definitely affect paralleling
things,
we must guarantee the CGroup mounted by testA shouldn't be scanned/used
by testB, otherwise, it will fail in the cleanup phase. But, we can make
the LTP
test mounted CGroup path is transparent to others just by adding a special
string
like "ltp-cgroup".


-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20211203/fb0d62c7/attachment-0001.htm>