<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Cyril,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 25, 2021 at 11:24 PM Cyril Hrubis <<a href="mailto:chrubis@suse.cz" target="_blank">chrubis@suse.cz</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">Hi!<br>
> Since previously swapping01 read the system FreeSwap for counting<br>
> usage of swap-size, that's not precise on system especially with<br>
> eating-memory daemon??in the background. Now, we try to check the<br>
> 'VmmSwap' in proc/PID/status??per process, to get rid of??the potential<br>
> influence from??other processes??which easily leads to false positive.<br>
<br>
I've been looking for a while at the kernel commit:<br>
<br>
commit 50a15981a1fac7e019ff7c3cba87531fb580f065<br>
Author: Martin Schwidefsky <<a href="mailto:schwidefsky@de.ibm.com" target="_blank">schwidefsky@de.ibm.com</a>><br>
Date:   Sun Jul 24 10:47:59 2011 +0200<br>
<br>
    [S390] reference bit testing for unmapped pages<br>
<br>
For which this test seems to be a reproducer and as far as I can tell<br>
this fix is not correct.<br>
<br>
If I understand correctly what we are trying to test here is that the<br>
kernel will not attempt to swap out unreferenced pages, so we have to,<br>
by definition, look at the system counters not the process ones.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Thanks for point out this! Seems we were all working towards</div><div class="gmail_default" style="font-size:small">making the test robust but neglect it's a reproducer:).</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As we have discussed many unsure things will take side effect to</div><div class="gmail_default" style="font-size:small">the system swap-counting, that's what we do NOT want to expect.</div><div class="gmail_default" style="font-size:small">Maybe, can we encapsulate all of the means in a process to avoid</div><div class="gmail_default" style="font-size:small">involving the whole system swap-counting. e.g.</div><div class="gmail_default" style="font-size:small"><br>Child:<br>         to touch unreferenced pages (via alloc&write&free 1.3*MemAvailable) [1]</div><div class="gmail_default" style="font-size:small">         alloc&wirte 1.3*MemAvailable</div><div class="gmail_default" style="font-size:small">         raise(SIGSTOP)</div><div class="gmail_default" style="font-size:small">         ...</div><div class="gmail_default" style="font-size:small">Parent:</div><div class="gmail_default" style="font-size:small">         waiting for child suspension<br>         check child's VmSwap to see if heavy-swap occurs in a process<br></div><div class="gmail_default" style="font-size:small">         ...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Does this make some sense to the test or, any else suggestion?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[1] As to perform alloc&write&free, the system pages will go through a</div><div class="gmail_default" style="font-size:small">completed life cycle from buddy-system to active-list to inactive-list</div><div class="gmail_default" style="font-size:small">then back to buddy-system, which reflect to a page status is theoretically like:</div><div class="gmail_default" style="font-size:small">"inactive,unreferenced -> active,referenced -> ... ->inactive,unreferenced"</div><div class="gmail_default" style="font-size:small">so that might helpful to produce what the kernel target commit fixed situation.</div><div class="gmail_default" style="font-size:small"><br></div></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>