On Mon, Dec 19, 2016 at 02:45:34PM +0100, Michal Hocko wrote: > Unfortunatelly shrink_active_list doesn't have any tracepoint so we do > not know whether we managed to rotate those pages. If they are referenced > quickly enough we might just keep refaulting them... Could you try to apply > the followin diff on top what you have currently. It should add some more > tracepoint data which might tell us more. We can reduce the amount of > tracing data by enabling only mm_vmscan_lru_isolate, > mm_vmscan_lru_shrink_inactive and mm_vmscan_lru_shrink_active. So, the results are in! I applied your patch and rebuild the kernel, then I rebooted the machine, set up tracing so that only the three events you mentioned were being traced, and captured the output over the network. Things went a bit different this time: The trace events started to appear after a while and a whole lot of them were generated, but suddenly they stopped. A short while later, we get [ 1661.485568] btrfs-transacti: page alloction stalls for 611058ms, order:0, mode:0x2420048(GFP_NOFS|__GFP_HARDWALL|__GFP_MOVABLE) along with a backtrace and memory information, and then there was silence. When I walked up to the machine, it had completely died; it wouldn't turn on its screen on key press any more, blindly trying to reboot via SysRequest had no effect, but the caps lock LED also wasn't blinking, like it normally does when a kernel panic occurs. Good question what state it was in. The OOM reaper didn't really seem to kick in and kill processes this time, it seems. The complete capture is up at: http://ftp.tisys.org/pub/misc/teela_2016-12-20.log.xz Greetings Nils -- 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>