All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3 1/2] API/cgroup: Expose memory_recursiveprot V2 mount opt
Date: Mon, 28 Feb 2022 09:22:54 +0000	[thread overview]
Message-ID: <87y21via5o.fsf@suse.de> (raw)
In-Reply-To: <20220222145311.GB12037@blackbody.suse.cz>

Hello Michal,

Michal Koutný <mkoutny@suse.com> writes:

> On Tue, Feb 22, 2022 at 12:45:46PM +0000, Richard Palethorpe <rpalethorpe@suse.com> wrote:
>> This changes the effect of trunk nodes' memory.low and memory.min on
>> their leaf nodes. So we need to change the expectations of some tests.
>
> How much are LTP runs striving to not affect environment?

As a general rule we try to leave the environment as we found it so that
testing is more deterministic. For the CGroup testing in particular I
decided not to change anything so that we do not have to worry about how
the init system will react.

> IIRC, the memory_recursiveprot is "remountable"; in the long-term it's
> likely worth watching the memory_recursiveprot behavior only.
>
> I.e. instead of carrying two sets of expectations you can warp the
> environment for the set that's more likely.
>
> Michal

Thinking about it, the reason why I was testing without
memory_recursiveprot is because I'm just direct booting the kernel with
bash as init and running the test. So the LTP is mounting the CGroups
and it should mount with memory_recursiveprot, but it is not.

Probably we have to support older products as well which don't have
memory_recursiveprot enabled and are using V2 (unlikely I guess, but it
is safest to assume this is the case). So we can still run the test, but
report CONF instead of PASS/FAIL. This way we will at least still catch
kernel warnings and panics.

-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2022-02-28 10:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-22 12:45 [LTP] [PATCH v3 0/2] memcontrol04 Richard Palethorpe via ltp
2022-02-22 12:45 ` [LTP] [PATCH v3 1/2] API/cgroup: Expose memory_recursiveprot V2 mount opt Richard Palethorpe via ltp
2022-02-22 14:53   ` Michal Koutný via ltp
2022-02-28  9:22     ` Richard Palethorpe [this message]
2022-03-01  3:28       ` Li Wang
2022-02-22 12:45 ` [LTP] [PATCH v3 2/2] memcontrol04: Copy from kselftest Richard Palethorpe via ltp
2022-02-22 14:45   ` Michal Koutný via ltp
2022-03-01  4:14     ` Li Wang
2022-03-01  3:55   ` 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=87y21via5o.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=ltp@lists.linux.it \
    --cc=mkoutny@suse.com \
    /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.