Re: [PATCH] mm/page_alloc: Wait for oom_lock before retrying.

[Michal Hocko <mhocko@suse.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>