On Wed 14-12-16 22:36:29, Tetsuo Handa wrote: > 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, Well, the problem is when the ringbuffer overflows and then we lose older data - and the stack as well. But I agree that dumping it for each allocation is a lot of noise. We can be more clever than that but this is more complicated I guess. A global ratelimit will not work and we most probably do not want to have per task ratelimit I believe because that sounds too much. > 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. The thing is that we want occasional show_mem because we want to see how the situation with the memory counters evolves over time. -- 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>