From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CDBDC3815B for ; Mon, 20 Apr 2020 07:33:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 66428206E9 for ; Mon, 20 Apr 2020 07:33:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 66428206E9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F230E8E0005; Mon, 20 Apr 2020 03:33:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED3E88E0003; Mon, 20 Apr 2020 03:33:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC1BC8E0005; Mon, 20 Apr 2020 03:33:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id C1FDD8E0003 for ; Mon, 20 Apr 2020 03:33:09 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 715DF180ACF8F for ; Mon, 20 Apr 2020 07:33:09 +0000 (UTC) X-FDA: 76727417298.07.shelf19_8fee88fbee719 X-HE-Tag: shelf19_8fee88fbee719 X-Filterd-Recvd-Size: 2619 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Apr 2020 07:33:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8A1F8AECE; Mon, 20 Apr 2020 07:33:06 +0000 (UTC) Date: Mon, 20 Apr 2020 09:33:05 +0200 From: Michal Hocko To: Tetsuo Handa Cc: akpm@linux-foundation.org, guro@fb.com, linux-mm , rientjes@google.com, shakeelb@google.com, Yafang Shao Subject: Re: [nacked] mm-oom-avoid-printk-iteration-under-rcu.patch removed from -mm tree Message-ID: <20200420073305.GD27314@dhcp22.suse.cz> References: <20200131043324.wkArXTf6-%akpm@linux-foundation.org> <20200417152637.GQ26707@dhcp22.suse.cz> <68371d79-dfae-e9b9-38df-dbb916607a82@i-love.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68371d79-dfae-e9b9-38df-dbb916607a82@i-love.sakura.ne.jp> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat 18-04-20 19:13:57, Tetsuo Handa wrote: [...] > > For the specific issue that you are pointing out, a simple and working > > workaround is to reduce the loglevel or disable dump_tasks. There is no > > real reason to add ugly kluges IMHO. > > I do need dump_tasks() output in order to understand memory usage as of > invocation of the OOM killer (rather than verifying whether the OOM killer > chose appropriate OOM victim). I really do not want to reduce the loglevel > or disable dump_tasks(). > > You are misunderstanding the problem. Asynchronous printk() cannot solve a problem > that printk() buffer is needlessly flooded with OOM related messages, which can > result in loss of non OOM-related messages if console is slow and can result in > bloating of log files if console is not slow. I do agree with this statement. And that is the _primamry_ point why I believe your patch doesn't solve _anything_. Why? Because it doesn't reduce the amount of the output. You merely shift it to a different context which adds complexity as I've mentioned already. The only thing you really "fix" is that the potentially long taking printk is not done from the locked oom context. This is what the async printk will address AFAIU. That being said, this is not the first time we are in this discussion and I find repeating the same thing unproductive. -- Michal Hocko SUSE Labs