[LTP] [PATCH v3 2/2] memcontrol04: Copy from kselftest

Li Wang liwang@redhat.com
Tue Mar 1 05:14:56 CET 2022


On Tue, Feb 22, 2022 at 10:45 PM Michal Koutný <mkoutny@suse.com> wrote:

> Hello.
>
> On Tue, Feb 22, 2022 at 12:45:47PM +0000, Richard Palethorpe <
> rpalethorpe@suse.com> wrote:
> > + * "First, this test creates the following hierarchy:
> > + * A       memory.low = 50M,  memory.max = 200M
> > + * A/B     memory.low = 50M,  memory.current = 50M
> > + * A/B/C   memory.low = 75M,  memory.current = 50M
> > + * A/B/D   memory.low = 25M,  memory.current = 50M
> > + * A/B/E   memory.low = 500M, memory.current = 0
> > + * A/B/F   memory.low = 0,    memory.current = 50M
> > + *
> > + * Usages are pagecache
> > + * Then it creates A/G and creates a significant
> > + * memory pressure in it.
> > + *
> > + * A/B    memory.current ~= 50M
> > + * A/B/C  memory.current ~= 33M
> > + * A/B/D  memory.current ~= 17M
> > + * A/B/E  memory.current ~= 0
>
> This nicely misses the expected consumption of the F cgroup (I see it's
>

+1



> missing in the original too). But one can expect from complementarity
> it's zero (if one accepts these values, which unfortunately is not true
> with hierarchical & scaled reclaim protection).
>
> > +             if (i < E || (i == F && tst_cg_memory_recursiveprot())) {
> > +                     TST_EXP_EXPR(low > 0,
> > +                                  "(%c low events=%ld) > 0", id, low);
> > +             } else {
> > +                     TST_EXP_EXPR(low == 0,
> > +                                  "(%c low events=%ld) == 0", id, low);
> > +             }
>
> Despite this makes the test behavior consistent, I think this is
> unexpected behavior with recursive_memoryprot. With the given
> configuration, there should never be residual protection that F assumes.
>
> Unless there is a good explanation [1], I'd consider non-zero
> memory.events:low in F the test failure here.
>

Hmm, the documentation does not give an explicit description for
recursive_memoryprot. If things like you said, it is more like a
CGroup bug in the kernel.

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


More information about the ltp mailing list