Tetsuo Handa wrote on 12/05/17 20:26:
On 2017/05/12 17:51, Arthur Marsh wrote:
I've been building the Linus git head kernels as the source gets updated and
the one built about 3 hours ago managed to get stuck with kswapd0 as the highest
consumer of CPU cycles (but still under 1 percent) of processes listed by top for
over 15 minutes, after which I hit the power switch and rebooted with a Debian
4.11.0 kernel.
Did the /bin/top process continue showing up-to-dated statistics rather than
refrain from showing up-to-dated statistics? (I wonder why you had to hit
the power switch before trying SysRq-m/SysRq-f etc.)
Yes, the /bin/top process continued updating.
The load average reached a high figure (over 14).
kswapd0 was using more CPU cycles than anything else but was still under
1 percent.
There was still a lot of swap space free (about 3 GiB).
buffer/cache dropped below 1 GiB out of 8 GiB RAM.
I would have used alt-sysrq-f but had only recently enabled it in my
kernel builds and didn't think to look it up on my other pc.
If yes, assuming that reading statistics involves memory allocation requests,
there was no load at at all despite firefox and chromium were running?
Wait time was over 98 percent, load average over 14.
If no, all allocation requests got stuck waiting for memory reclaim?
...
More description of what happened and how you confirmed that
the /bin/top process continued working would be helpful.
It was as if kswapd0 was just left waiting to swap pages in and out
without any other processes getting to complete what they were trying to do.
It does seem to be related to chromium starting up several processes
when opening extra windows/tabs.
Thanks for your help!
Arthur.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
