Michal Hocko wrote: > On Wed 14-12-16 13:36:44, Petr Mladek wrote: > [...] > > There are basically two solution for this situation: > > > > 1. Fix printk() so that it does not block forever. This will > > get solved by the async printk patchset[*]. In the meantime, > > a particular sensitive location might be worked around > > by using printk_deferred() instead of printk()[**] > > Absolutely! > > > 2. Reduce the amount of messages. It is insane to report > > the same problem many times so that the same messages > > fill the entire log buffer. Note that the allocator > > is not the only sinner here. > > sure and the ratelimit patch should help in that direction. > show_mem for each allocation stall is really way too much. dump_stack() from warn_alloc() for each allocation stall is also too much. Regarding synchronous watchdog like warn_alloc(), each thread's backtrace never change for that allocation request because it is always called from the same location (i.e. __alloc_pages_slowpath()). Backtrace might be useful for the first time of each thread's first allocation stall report for that allocation request, but subsequent ones are noises unless backtrace of the first time was corrupted/dropped, for they are only saying that allocation retry loop did not get stuck inside e.g. shrink_inactive_list(). Maybe we don't need to call warn_alloc() for each allocation stall; call warn_alloc() only once and then use one-liner report. -- 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>