Re: [nacked] mm-oom-avoid-printk-iteration-under-rcu.patch removed from -mm tree

From: Yafang Shao <laoar.shao@gmail.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Michal Hocko <mhocko@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Roman Gushchin <guro@fb.com>, linux-mm <linux-mm@kvack.org>,
	David Rientjes <rientjes@google.com>,
	 Shakeel Butt <shakeelb@google.com>
Subject: Re: [nacked] mm-oom-avoid-printk-iteration-under-rcu.patch removed from -mm tree
Date: Thu, 23 Apr 2020 14:35:22 +0800	[thread overview]
Message-ID: <CALOAHbAMa_WGWodAoFCerKhYuY89Vcv1d2rXz0mu2tCMFQHaNA@mail.gmail.com> (raw)
In-Reply-To: <0aa5e490-c5b8-dc5c-334e-9a8d37da215c@i-love.sakura.ne.jp>

On Thu, Apr 23, 2020 at 1:35 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2020/04/22 15:59, Michal Hocko wrote:
> >>>                              This is what the async printk will address
> >>> AFAIU.
> >>
> >> No! You are completely wrong!! Async printk CANNOT reduce the amount of the
> >> output.
> >
> > Which is exactly what I claim above. Async printk would, however, deal
> > with the problem of the locked context part of the problem because
> > the heavy lifting is not done from the caller context. Please read my
> > response carefully.
>
> No! My proposal (which offloads to a deferrable context) avoids doing the
> heavy lifting (for printk buffer users) from the printk caller context. I'm
> saying that "don't pile up too much backlog onto the printk buffer (by abusing
> async printk) in order to make sure that kernel messages which are more
> important than reporting OOM victim candidates will be processed immediately".
>
> dump_tasks() remains definitely a printk() abuser which is capable of pushing
> many thousands of printk() messages in one second if async printk were available.
> Async printk CANNOT deal with the problem that too much backlog causes important
> messages to be delayed for too long. Please read my explanation carefully.
>

Agreed. Too much oom reports still be a issue even if the printk() is asyn.
I think the aysnc printk() won't care about wheter the data is
improtant or not, so the user of printk() (even if it is asyn) should
have a good management of these data especially if these data may
consume all or most of the printk buffer.

> Also, Sergey Senozhatsky (printk maintainer) said at
> https://lkml.kernel.org/r/20200423015008.GA246741@jagdpanzerIV.localdomain
> that it is UNKNOWN when async printk is merged. Async printk is not a
> silver-bullet breakthrough. Async printk cannot work without cooperation from
> printk() users. Please really stop letting the printk() do the heavy lifting.
>

-- 
Thanks
Yafang