<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 28, 2022 at 5:59 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de">rpalethorpe@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Michal,<br>
<br>
Michal Koutný <<a href="mailto:mkoutny@suse.com" target="_blank">mkoutny@suse.com</a>> writes:<br>
<br>
> On Tue, Feb 22, 2022 at 12:45:46PM +0000, Richard Palethorpe <<a href="mailto:rpalethorpe@suse.com" target="_blank">rpalethorpe@suse.com</a>> wrote:<br>
>> This changes the effect of trunk nodes' memory.low and memory.min on<br>
>> their leaf nodes. So we need to change the expectations of some tests.<br>
><br>
> How much are LTP runs striving to not affect environment?<br>
<br>
As a general rule we try to leave the environment as we found it so that<br>
testing is more deterministic. For the CGroup testing in particular I<br>
decided not to change anything so that we do not have to worry about how<br>
the init system will react.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">+1</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> IIRC, the memory_recursiveprot is "remountable"; in the long-term it's<br>
> likely worth watching the memory_recursiveprot behavior only.<br>
><br>
> I.e. instead of carrying two sets of expectations you can warp the<br>
> environment for the set that's more likely.<br>
><br>
> Michal<br>
<br>
Thinking about it, the reason why I was testing without<br>
memory_recursiveprot is because I'm just direct booting the kernel with<br>
bash as init and running the test. So the LTP is mounting the CGroups<br>
and it should mount with memory_recursiveprot, but it is not.<br>
<br>
Probably we have to support older products as well which don't have<br>
memory_recursiveprot enabled and are using V2 (unlikely I guess, but it<br>
is safest to assume this is the case). So we can still run the test, but<br>
report CONF instead of PASS/FAIL. This way we will at least still catch<br>
kernel warnings and panics.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">This sounds reasonable at least to me.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Reviewed-by: Li Wang <<a href="mailto:liwang@redhat.com">liwang@redhat.com</a>></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>