On 9/17/2020 10:45 PM, Michal Hocko wrote:
On Thu 17-09-20 11:03:56, Vijay Balakrishna wrote:
[...]
The auto tuned value is incorrect post hotplug memory operation, in our use
case memoy hot add occurs very early during boot.
Define incorrect. What are the actual values? Have you tried to increase
the value manually after the hotplug?
In our case SoC with 8GB memory, system tuned min_free_kbytes
- first to 22528
- we perform memory hot add very early in boot
What was the original and after-the-hotplug size of memory and layout?
I suspect that all the hotplugged memory is in Movable zone, right?
Yes, added ~1.92GB as Movable type, booting with 6GB at start.
- now min_free_kbytes is 8703
Before looking at code, first I manually restored min_free_kbytes soon after
boot, reran stress and didn't notice symptoms I mentioned in change log.
This is really surprising and I strongly suspect that an earlier reclaim
just changed the timing enough so that workload has spread the memory
prpessure over a longer time and that might have been enough to recycle
some of the unreclaimable memory due to its natural life time. But this
is a pure speculation. Much more data would be needed to analyze this.
In any case your stress test is oveprovisioning your Normal zone and
increased min_free_kbytes just papers over the sizing problem.
It is a synthetic workload, likely not sized I need to check. I feel
having higher min_free_kbytes made GFP_ATOMIC allocations not to fail.
I have seen NETDEV WATCHDOG timeout with stacktrace trying to allocate
memory, looping in net rx receive path.
Thanks,
Vijay
