From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [RFC PATCH 2/5] CGroup API rewrite
Date: Wed, 20 Jan 2021 10:18:52 +0000 [thread overview]
Message-ID: <87pn1zap2r.fsf@suse.de> (raw)
In-Reply-To: <CAEemH2ddvRZ5YjvGkAbR8rmPfgEHv8O5Q+zFch_2pk0+0avrHw@mail.gmail.com>
Hello Li,
Li Wang <liwang@redhat.com> writes:
> Hi Richard,
>
> Richard Palethorpe <rpalethorpe@suse.de> wrote:
>
>> ...
>> >> > As I was mentioned in 0/5 that maybe we should create test_cgroup_dir
>> >> > for different progress so that the test could use the same controller
>> >> with
>> >> > various configurations in parallel.
>> >> >
>> >> > e.g. child_1 set SIZE to memory.limit_in_bytes
>> >> > child_2 set SIZE/2 to memory.limit_in_bytes
>> >> >
>> >> > Any possibility to move this to tst_cgroup_move_current?
>> >>
>> >> Yes I suppose we can try this. Is there a test which already requires
>> it?
>> >>
>> >
>> > So far we don't have such a test, I remember that in the previous Lib is
>> > also to keep expandability.
>>
>> I think we have at least two problems:
>>
>> 1) This allows many CGroups to be created for each test and we must
>> clean them up, adding some complication.
>>
>> 2) It's not clear if a future test will require the CGroup hierarchy to
>> be the same as the process hierarchy or different. Depending what
>> behaviour for tst_cgroup_move_current we choose it will make some
>> configurations impossible.
>>
>> So if we add this then it will add complexity, but I am not sure it will
>> help in the future. If we make it flexible enough to support any
>> hierarchy this will add a lot of complication.
>>
>
> Okay. I do NOT insist to implement a future feature at this early
> moment, but do u think we'd better mention this in documents?
> To let people(avoid abusing it) know that the current CGroup lib
> hasn't supported children using the same controller in parallel?
Yes, this is a good point.
>
> And another new query is, do we really need to export many
> cleanup-levels to users? I guess we can handle it in the library
> with intelligently choose levels no matter in parallel or sequential.
No, I should remove it. I was using it for debugging, but there is
probably a simpler way.
>
> i.e. As now only one directory(test-pid/) created for one test in a
> hierarchy, how about going with TST_CGROUP_CLEANUP_ROOT
> level by default, unless it detects more or equal to two directories
> (that probably means parallel) goes TST_CGROUP_CLEANUP_TEST?
That is likely to result in race conditions. However it won't cleanup
any CGroups which already exist (except the test CGroup). So the user
can pre-create the LTP CGroup before running tests in parallel.
>
>
>>
>> Also if we did need this feature in the future, then we can add some new
>> functions which take a sub-group (or hierarchy) parameter. e.g.
>>
>> void tst_cgroup_move(enum tst_cgroup_ctrl type, pid_t pid,
>> struct tst_cgroup_tree *path);
>>
>
> Sounds good to me.
>
>
>>
>> Alternate versions of other functions would also need to be added. Also
>> some changes to the internal data structures may be needed. However it
>> would keep the current API functions simple.
>>
>> So until we have a test which requires this, I think the best option is
>> to do nothing :-)
>>
>> --
>> Thank you,
>> Richard.
>>
>>
--
Thank you,
Richard.
next prev parent reply other threads:[~2021-01-20 10:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 10:01 [LTP] [RFC PATCH 0/5] CGroups Richard Palethorpe
2020-12-16 10:01 ` [LTP] [RFC PATCH 1/5] safe_file_ops: Introduce openat and printfat API Richard Palethorpe
2020-12-16 10:01 ` [LTP] [RFC PATCH 2/5] CGroup API rewrite Richard Palethorpe
2021-01-02 9:18 ` Li Wang
2021-01-04 9:24 ` Richard Palethorpe
2021-01-04 10:03 ` Li Wang
2021-01-19 12:15 ` Richard Palethorpe
2021-01-20 9:44 ` Li Wang
2021-01-20 10:18 ` Richard Palethorpe [this message]
2020-12-16 10:01 ` [LTP] [RFC PATCH 3/5] CGroup API tests Richard Palethorpe
2021-01-02 9:23 ` Li Wang
2020-12-16 10:01 ` [LTP] [RFC PATCH 4/5] CGroup test guidelines Richard Palethorpe
2020-12-16 10:01 ` [LTP] [RFC PATCH 5/5] cgroups: convert tests to use API rewrite Richard Palethorpe
2020-12-31 11:19 ` [LTP] [RFC PATCH 0/5] CGroups Li Wang
2021-01-04 9:16 ` Richard Palethorpe
2021-01-04 10:00 ` Li Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pn1zap2r.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox