<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 26, 2021 at 1:25 PM Li Wang <<a href="mailto:liwang@redhat.com">liwang@redhat.com</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"><div dir="ltr"><div dir="ltr"><div 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 style="font-size:small">Thanks for point out this! Seems we were all working towards</div><div style="font-size:small">making the test robust but neglect it's a reproducer:).</div></div><div style="font-size:small"><br></div><div style="font-size:small"><br></div><div style="font-size:small">As we have discussed many unsure things will take side effect to</div><div style="font-size:small">the system swap-counting, that's what we do NOT want to expect.</div><div style="font-size:small">Maybe, can we encapsulate all of the means in a process to avoid</div><div style="font-size:small">involving the whole system swap-counting. e.g.</div><div style="font-size:small"><br>Child:<br>         to touch unreferenced pages (via alloc&write&free 1.3*MemAvailable) [1]</div><div style="font-size:small">         alloc&wirte 1.3*MemAvailable</div><div style="font-size:small">         raise(SIGSTOP)</div><div style="font-size:small">         ...</div><div style="font-size:small">Parent:</div><div 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 style="font-size:small">         ...</div><div style="font-size:small"><br></div><div style="font-size:small">Does this make some sense to the test or, any else suggestion?</div><div style="font-size:small"><br></div><div style="font-size:small">[1] As to perform alloc&write&free, the system pages will go through a</div><div style="font-size:small">completed life cycle from buddy-system to active-list to inactive-list</div><div style="font-size:small">then back to buddy-system, which reflect to a page status is theoretically like:</div><div style="font-size:small">"inactive,unreferenced -> active,referenced -> ... ->inactive,unreferenced"</div><div style="font-size:small">so that might helpful to produce what the kernel target commit fixed situation.</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">To verify this assumption, I run the swapping01 with/without my patch-V2</div><div class="gmail_default" style="font-size:small">against an unfix-kernel(2.6.39). Seems swap out unreferenced pages also</div><div class="gmail_default" style="font-size:small">could be occurred in a single process, which gives me some confidence to</div><div class="gmail_default" style="font-size:small">send out my patch V2.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">-------</div><div class="gmail_default" style="font-size:small">Reproduce the bug easily with an unfix-kernel<br><br># uname  -r<br>2.6.39<br><br># free -m<br>             total       used       free     shared    buffers     cached<br>Mem:          2006       1559        447          0         22       1359<br>-/+ buffers/cache:        178       1828<br>Swap:         4031         12       4019<br><br># ./swapping01 <br>tst_test.c:1263: TINFO: Timeout per run is 0h 05m 00s<br>swapping01.c:110: TINFO: available physical memory: 1896 MB<br>swapping01.c:113: TINFO: try to allocate: 2466 MB<br>swapping01.c:148: TFAIL: heavy swapping detected: 1905 MB swapped.<br></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>