Re: [PATCH] mm,page_alloc: Serialize warn_alloc() if schedulable.

[Petr Mladek <pmladek@suse.com>]

On Tue 2017-07-11 15:49:00, Michal Hocko wrote:
> On Tue 11-07-17 22:10:36, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Mon 10-07-17 22:54:37, Tetsuo Handa wrote:
> > > > What makes this situation worse is, since warn_alloc() periodically appends to
> > > > printk() buffer, the thread inside the OOM killer with oom_lock held can stall
> > > > forever due to cond_resched() from console_unlock() from printk().
> > > 
> > > warn_alloc is just yet-another-user of printk. We might have many
> > > others...

> because you are trying to address a problem at a wrong layer. If there
> is absolutely no way around it and printk is unfixable then we really
> need a printk variant which will make sure that no excessive waiting
> will be involved. Then we can replace all printk in the oom path with
> this special printk.

The last theory about printk offloading suggests that printk() should
always try to push some messages to the console when the console lock is
available. Otherwise, the messages might not appear at all because
the offloading is never 100% reliable, especially when the system is
in troubles.

In each case, this live-lock is another reason to risk the printk
offload at some stage.

Of course, we could make the throttling more aggressive. But it
is another complex problem. Only printk() knows how much it is
stressed and how much throttling is needed. On the other hand,
it might be hard to know what information is repeating and
who need to be throttled. It is a question if it should be
solved by providing more printk_throttle() variants or
by some magic inside normal printk().

Best Regards,
Petr

--
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>