[LTP] 答复: [PATCH] memcg_use_hierarchy_test.sh: skip setting use_hierarchy if not available
Li Wang
liwang@redhat.com
Wed Oct 14 08:27:33 CEST 2020
On Tue, Oct 13, 2020 at 11:19 AM Yang Xu <xuyang2018.jy@cn.fujitsu.com>
wrote:
> 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?
>
I'm ok to go with memory.use_hierarchy checking in the preconditioning
phase.
But how can you assert the default memory cgroup is mount at path:
"/sys/fs/cgroup/memory", is there any possibility the default path mount at
other places(for different distribution)?
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20201014/932b3f8b/attachment.htm>
More information about the ltp
mailing list