[LTP] [PATCH 10/16] controllers: Update memcg_control_test to newer test lib and cgroup lib

[Li Wang]

Hi Luke,

Thanks for looking back and working on this.

On Thu, Mar 3, 2022 at 5:38 AM Luke Nowakowski-Krijger <
luke.nowakowskikrijger@canonical.com> wrote:

> Hi Li,
>
> On Mon, Jan 24, 2022 at 1:44 AM Li Wang <liwang@redhat.com> wrote:
>
>> Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> wrote:
>>
>> As we already built the controller files mapping from V2 to V1
>> in C library and you actually add many new (in patch 5/16).
>>
>> I'm thinking maybe we could make use of it in tst_cgctl.c to
>> avoid handling these (in shell) separately.
>>
>> Something like:
>>
>>     # ./tst_cgctl  set  "$pid"  "cgroup.procs"  "$target_pid"
>>     # ./tst_cgctl  set  "$pid"  "memory.max"  "$ACTIVE_MEM_LIMIT"
>>
>> Otherwise, it seems to make no sense to add so many new
>> files mapping (like that patch 5/16) at this moment.
>>
>> What do you think?
>>
>>
>> I think this would be nice except that we would need to keep track of the
> tst_cg_cgroup structs if we wanted to use safe_cg_* functions in the C lib.
> This would be fine if we only wanted to use control files in the test_dir
> but it gets more complicated if there are other directories below it that
> we would want to set. At least as far as I understand it.
>

Right, but so far it seems we don't have more (than two) sub-layer
directories tests.
(or maybe I didn't aware that we have)

>
> And as Richard mentioned its probably a better idea to just only add the
> control files for controllers as we absolutely need them so this wouldn't
> be too useful. Plus I think it's easy enough from shell to do a version
> check and write to the right control file/directory directly.
>
> So I personally don't think its as important, but I could see in the
> future implementing something like this so it mimics the C api. What do you
> think?
>

Yes, it will be a little bit complex to achieve if we decide to
encapsulate more details in tst_cgctl.c.
But I just hope to provide a simple enough and intuitive way
to use CGroup to LTP shell users. Giving more flexible to shell
API also means giving more complexity to handle problem and
easy to make mistakes.

Anyway, I don't strongly insist on going like that, feel free to send
out the next patch version as you wanted. I believe we will keep
improving the API and tests later, or we can change to that if we
find it is really neccesary.

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