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.) If yes, assuming that reading statistics involves memory allocation requests, there was no load at at all despite firefox and chromium were running? If no, all allocation requests got stuck waiting for memory reclaim? > > The previous kernel built less than 24 hours earlier did not have this problem. > > CPU is an Athlon64 (Athlon II X4, 4 cores), RAM is 8GiB, swap is 4GiB, load was > mainly firefox and chromium. Opening a new window in chromium seemed to help > trigger the problem. > > It's not much information to go on, just wondered if anyone else had experienced > similar issues? > > I'm happy to supply more configuration information and run tests including with > kernels built with test patches applied. I don't know but http://lkml.kernel.org/r/20170316100409.GR802@xxxxxxxxxxxxxxxxxxxxxxxx or http://lkml.kernel.org/r/20170502041235.zqmywvj5tiiom3jk@xxxxxxxxxxx ? More description of what happened and how you confirmed that the /bin/top process continued working would be helpful. -- 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>
