<div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> Therically this is correct, and I believe it will work on your tested<br>
>> machine.<br>
>><br>
>> But my concern is ioctl_sg01 still fails on the special system which<br>
>> MemAvai < MemFree.<br>
>><br>
>> Just like the one Xinpeng mentioned before:<br>
>> <a href="https://lists.linux.it/pipermail/ltp/2021-January/020817.html" rel="noreferrer" target="_blank">https://lists.linux.it/pipermail/ltp/2021-January/020817.html</a><br>
>> <<a href="https://lists.linux.it/pipermail/ltp/2021-January/020817.html" rel="noreferrer" target="_blank">https://lists.linux.it/pipermail/ltp/2021-January/020817.html</a>><br>
>><br>
>> [root@test-env-nm05-compute-14e5e72e38<br>
>> <mailto:<a href="mailto:root@test-env-nm05-compute-14e5e72e38" target="_blank">root@test-env-nm05-compute-14e5e72e38</a>>~]# cat /proc/meminfo<br>
>><br>
>> MemTotal:       526997420 kB<br>
>> MemFree:        520224908 kB<br>
>> MemAvailable:   519936744 kB<br>
>> ...<br>
>><br>
>> [root@test-env-nm05-compute-14e5e72e38 <mailto:<a href="mailto:root@test-env-nm05-compute-14e5e72e38" target="_blank">root@test-env-nm05-compute-14e5e72e38</a>> ~]# cat  /proc/sys/vm/min_free_kbytes<br>
>> 90112<br>
>><br>
>><br>
>> There even reserve the safety to the 128MB, still less than the gap<br>
>> between MemFree and MemAvailable. <br>
>><br>
>> MemFree (520224908 kB) - MemAvailable (520224908 kB) = 288164 kB  > safety<br>
> <br>
> I don't have such case and I am not sure it is reasonable.<br>
> <br>
> As mentioned in the thread there it looks unusual to have less available<br>
> memory than free. Maybe the system has some weird memory accounting<br>
> because MemAvailable is counted from MemFree by adding memory which can<br>
> be reclaimed. When adding a non-negative number, you should not end up<br>
> with lower MemAvailable than MemFree. :)<br>
> <br>
> Maybe that's the reason why that patch was not accepted - the system is<br>
> not vanilla, not common?<br>
<br>
OK, I found a possible explanation (on vanilla kernel) - the<br>
totalreserve_pages. This is the only subtraction from free memory when<br>
counting available. This could happen if someone was setting sysctl<br>
lowmem_reserve_ratio or min_free_kbytes.<br></blockquote><div><br></div><div><div class="gmail_default">That's exactly, beside the two controllers, you could also get such</div><div class="gmail_default">a system with enabling smaller swap space on aarch64/x86_64.</div><div class="gmail_default"><br></div><div class="gmail_default">(I did that and found that 'MemFree > MemAvail' is common to see)</div></div><div><br></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>
When setting min_free_kbytes, this will be reflected in<br>
/proc/sys/vm/min_free_kbytes, so we are good.<br>
<br>
When setting vm.lowmem_reserve_ratio, this will be missed by my patch<br>
and MemAvailable could be lower than MemFree.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, we have to face different kinds of system configuration in testing.</div><div class="gmail_default"><br></div><div class="gmail_default">Maybe we'd better keep the (info.freeram/64) in MAX() as well,</div><div class="gmail_default">Or, do a comparison between MemFree and MemAvail to choose</div><div class="gmail_default" style="font-size:small">the smaller one as baseline.</div></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>