On Thu 22-12-16 11:10:29, Nils Holland wrote: > On Wed, Dec 21, 2016 at 08:36:59AM +0100, Michal Hocko wrote: > > TL;DR > > there is another version of the debugging patch. Just revert the > > previous one and apply this one instead. It's still not clear what > > is going on but I suspect either some misaccounting or unexpeted > > pages on the LRU lists. I have added one more tracepoint, so please > > enable also mm_vmscan_inactive_list_is_low. > > Right, I did just that and can provide a new log. I was also able, in > this case, to reproduce the OOM issues again and not just the "page > allocation stalls" that were the only thing visible in the previous > log. Thanks a lot for testing! I will have a look later today. > However, the log comes from machine #2 again today, as I'm > unfortunately forced to try this via VPN from work to home today, so I > have exactly one attempt per machine before it goes down and locks up > (and I can only restart it later tonight). This is really surprising to me. Are you sure that you have sysrq configured properly. At least sysrq+b shouldn't depend on any memory allocations and should allow you to reboot immediately. A sysrq+m right before the reboot might turn out being helpful as well. -- Michal Hocko SUSE Labs -- 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>