<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 Wed, Oct 20, 2021 at 5:14 PM Krzysztof Kozlowski <<a href="mailto:krzysztof.kozlowski@canonical.com">krzysztof.kozlowski@canonical.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">Previous fix for an out-of-memory killer killing ioctl_sg01 process<br>
in commit 4d2e3d44fad5 ("lib: memutils: don't pollute<br>
entire system memory to avoid OoM") was not fully effective. While it<br>
covers most of the cases, an ARM64 machine with 128 GB of memory, 64 kB<br>
page size and v5.11 kernel hit it again. Polluting the memory fails<br>
with OoM:<br>
<br>
LTP: starting ioctl_sg01<br>
ioctl_sg01 invoked oom-killer: gfp_mask=0x100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0<br>
...<br>
Mem-Info:<br>
active_anon:309 inactive_anon:1964781 isolated_anon:0<br>
active_file:94 inactive_file:0 isolated_file:0<br>
unevictable:305 dirty:0 writeback:0<br>
slab_reclaimable:1510 slab_unreclaimable:5012<br>
mapped:115 shmem:339 pagetables:463 bounce:0<br>
free:112043 free_pcp:1 free_cma:3159<br>
Node 0 active_anon:19776kB inactive_anon:125745984kB active_file:6016kB inactive_file:0kB unevictable:19520kB ...<br>
Node 0 DMA free:710656kB min:205120kB low:256384kB high:307648kB reserved_highatomic:0KB active_anon:0kB inactive_anon:3332032kB ...<br>
lowmem_reserve[]: 0 0 7908 7908 7908<br>
Node 0 Normal free:6460096kB min:6463168kB low:8078912kB high:9694656kB reserved_highatomic:0KB active_anon:19776kB inactive_anon:122413952kB ...<br>
lowmem_reserve[]: 0 0 0 0 0<br>
<br>
The important part are details of memory on Node 0 in Normal zone:<br>
1. free memory: 6460096 kB<br>
2. min (minimum watermark): 6463168 kB<br>
<br>
Parse the /proc/sys/vm/min_free_kbytes which contains the free<br>
memory level used as minimum watermark (triggering OoM killer).<br>
<br>
Signed-off-by: Krzysztof Kozlowski <<a href="mailto:krzysztof.kozlowski@canonical.com" target="_blank">krzysztof.kozlowski@canonical.com</a>><br>
<br>
---<br>
<br>
Changes since v2:<br>
1. Use /proc/sys/vm/min_free_kbytes instead of parsing zoneinfo, thanks<br>
tgo Liu Xinpeng.<br>
<br>
Changes since v1:<br>
1. Add static and rename to count_min_pages().<br>
---<br>
lib/tst_memutils.c | 8 +++++++-<br>
1 file changed, 7 insertions(+), 1 deletion(-)<br>
<br>
diff --git a/lib/tst_memutils.c b/lib/tst_memutils.c<br>
index af132bcc6c24..df53c542d239 100644<br>
--- a/lib/tst_memutils.c<br>
+++ b/lib/tst_memutils.c<br>
@@ -16,12 +16,18 @@<br>
void tst_pollute_memory(size_t maxsize, int fillchar)<br>
{<br>
size_t i, map_count = 0, safety = 0, blocksize = BLOCKSIZE;<br>
+ unsigned long min_free;<br>
void **map_blocks;<br>
struct sysinfo info;<br>
<br>
+ SAFE_FILE_SCANF("/proc/sys/vm/min_free_kbytes", "%lu", &min_free);<br>
+ min_free *= 1024;<br>
+ /* Apply a margin because we cannot get below "min" watermark */<br>
+ min_free += min_free / 10;<br>
+<br>
SAFE_SYSINFO(&info);<br>
safety = MAX(4096 * SAFE_SYSCONF(_SC_PAGESIZE), 128 * 1024 * 1024);<br>
- safety = MAX(safety, (info.freeram / 64));<br>
+ safety = MAX(safety, min_free);<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Therically this is correct, and I believe it will work on your tested machine.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But my concern is ioctl_sg01 still fails on the special system which MemAvai < MemFree.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Just like the one Xinpeng mentioned before:</div><a href="https://lists.linux.it/pipermail/ltp/2021-January/020817.html">https://lists.linux.it/pipermail/ltp/2021-January/020817.html</a><br></div><div><br></div><div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);white-space:pre-wrap">[</span><a href="mailto:root@test-env-nm05-compute-14e5e72e38" style="white-space:pre-wrap">root@test-env-nm05-compute-14e5e72e38</a><span style="color:rgb(0,0,0);white-space:pre-wrap"> ~]# cat /proc/meminfo</span></div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">MemTotal: 526997420 kB
MemFree: <span class="gmail_default" style="font-size:small"></span><span class="gmail_default" style="font-size:small"></span><span class="gmail_default" style="font-size:small"></span>520224908 kB
MemAvailable: <span class="gmail_default" style="font-size:small"></span>519936744 kB
<span class="gmail_default" style="font-size:small">...</span>
[<a href="mailto:root@test-env-nm05-compute-14e5e72e38">root@test-env-nm05-compute-14e5e72e38</a> ~]# cat /proc/sys/vm/min_free_kbytes
90112
</pre><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There even reserve the safety to the 128MB, still less than the gap</div><div class="gmail_default" style="font-size:small">between MemFree and MemAvailable. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">MemFree (<span class="gmail_default" style="color:rgb(0,0,0);white-space:pre-wrap"></span><span style="color:rgb(0,0,0);white-space:pre-wrap">520224908 kB</span>) - MemAvailable (<span class="gmail_default" style="color:rgb(0,0,0);white-space:pre-wrap"></span><span style="color:rgb(0,0,0);white-space:pre-wrap">520224908 kB</span>) = 288164 kB > safety</div></div><div><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>