All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] 答复:  [PATCH] memcg_use_hierarchy_test.sh: skip setting use_hierarchy if not available
Date: Tue, 13 Oct 2020 11:19:51 +0800	[thread overview]
Message-ID: <5F851CD7.8030005@cn.fujitsu.com> (raw)
In-Reply-To: <ebd86e7d991642cbb13e3ce46d032a69@G08CNEXMBPEKD04.g08.fujitsu.local>

Hi Hanxiao

> Hi, Yang
>
>> -----????-----
>> ??: Re: [LTP] [PATCH] memcg_use_hierarchy_test.sh: skip setting
>> use_hierarchy if not available
>>
>> Hi hanxiao
>>
>>
>>> The precondition of this case is that we can disable use_hierarchy.
>>> But some distributions such as CentOS 8 had enabled it in root cgroup
>>> and hard to disabled.
> [snip]
>> /dev/memcg/memory.use_hierarchy" \
>>> +                                    "to 0 failed"
>>> +                        fi
>>> +                fi
>> I test this patch on centos7 and testcase2 skips. On centos7(without installing
>> docker), /sys/fs/cgroup/memory/memory.use_hierarchy value is equal to 1 and I
>> still can disable value for /dev/memcg/memory.use_hierarchy.
>>
> The behavior above looks conflicting with https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt.
Yes. Centos7 behavior is different from the documentation.
>> So why not directly use /dev/memcg/memory.use_hierarchy value to judge in
>> testcase after setting 0.
> In setup_test from memcg_lib.sh, we actually did:
>     mount -t cgroup -omemory memcg /dev/memcg
> Then kernel will find a suitable cgroup root for us in cgroup1_mount.
>
> In this case, /sys/fs/cgroup/memory/ would be the good choice.
> So it's equivalent to read memory.use_hierarchy from either side.
I understand. Only a minor suggestion, please use tabs instead of spaces
at the beginning of the line.


This patch looks good to me,
Acked-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>

@Li, I think this patch is ok, Do you have some comment about it?


Best Regards
Yang Xu


> Regards, 
> - Hanxiao
>> Best Regards
>> Yang Xu
>>>   	fi
>>>
>>>   	ROD mkdir "/dev/memcg/$TEST_ID"
>>> diff --git
>>> a/testcases/kernel/controllers/memcg/functional/memcg_use_hierarchy_te
>>> st.sh
>>> b/testcases/kernel/controllers/memcg/functional/memcg_use_hierarchy_te
>>> st.sh
>>> index 4cf6b9fc2..1439b6352 100755
>>> ---
>>> a/testcases/kernel/controllers/memcg/functional/memcg_use_hierarchy_te
>>> st.sh
>>> +++ b/testcases/kernel/controllers/memcg/functional/memcg_use_hierarch
>>> +++ y_test.sh
>>> @@ -34,7 +34,9 @@ TST_TOTAL=3
>>>   # test if one of the ancestors goes over its limit, the proces will be killed
>>>   testcase_1()
>>>   {
>>> -	echo 1 > memory.use_hierarchy
>>> +        if [ "$root_memory_use_hierarchy" != "1" ]; then
>>> +                echo 1 > memory.use_hierarchy
>>> +        fi
>>>   	echo $PAGESIZE > memory.limit_in_bytes
>>>
>>>   	mkdir subgroup
>>> @@ -48,6 +50,10 @@ testcase_1()
>>>   # test Enabling will fail if the cgroup already has other cgroups
>>>   testcase_2()
>>>   {
>>> +        if [ "$root_memory_use_hierarchy" = "1" ]; then
>>> +               tst_resm TCONF "root cgroup has use_hierarchy enabled,
>> skip"
>>> +               return
>>> +        fi
>>>   	mkdir subgroup
>>>   	EXPECT_FAIL echo 1 \> memory.use_hierarchy
>>>
>>> @@ -57,7 +63,9 @@ testcase_2()
>>>   # test disabling will fail if the parent cgroup has enabled hierarchy.
>>>   testcase_3()
>>>   {
>>> -	echo 1 > memory.use_hierarchy
>>> +        if [ "$root_memory_use_hierarchy" != "1" ]; then
>>> +               echo 1 > memory.use_hierarchy
>>> +        fi
>>>   	mkdir subgroup
>>>   	EXPECT_FAIL echo 0 \> subgroup/memory.use_hierarchy
>>>
>>>




  reply	other threads:[~2020-10-13  3:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11  9:21 [LTP] [PATCH] memcg_use_hierarchy_test.sh: skip setting use_hierarchy if not available Chen Hanxiao
2020-09-17  5:21 ` Yang Xu
2020-09-21 10:53   ` [LTP] 答复: " Chen, Hanxiao
2020-10-13  3:19     ` Yang Xu [this message]
2020-10-14  6:27       ` Li Wang
2020-10-14  7:31 Chen, Hanxiao

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=5F851CD7.8030005@cn.fujitsu.com \
    --to=xuyang2018.jy@cn.fujitsu.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.