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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 150C0C2BA19 for ; Thu, 23 Apr 2020 05:35:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ADEE0206B9 for ; Thu, 23 Apr 2020 05:35:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ADEE0206B9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 71AD98E0009; Thu, 23 Apr 2020 01:35:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CA918E0008; Thu, 23 Apr 2020 01:35:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B9BF8E0009; Thu, 23 Apr 2020 01:35:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3FD858E0008 for ; Thu, 23 Apr 2020 01:35:19 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 03A028248047 for ; Thu, 23 Apr 2020 05:35:19 +0000 (UTC) X-FDA: 76738006758.25.desk75_1131d8a4d7245 X-HE-Tag: desk75_1131d8a4d7245 X-Filterd-Recvd-Size: 3653 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Apr 2020 05:35:17 +0000 (UTC) Received: from fsav302.sakura.ne.jp (fsav302.sakura.ne.jp [153.120.85.133]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 03N5Z0fk094177; Thu, 23 Apr 2020 14:35:00 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav302.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav302.sakura.ne.jp); Thu, 23 Apr 2020 14:35:00 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav302.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 03N5YsET093997 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2020 14:35:00 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [nacked] mm-oom-avoid-printk-iteration-under-rcu.patch removed from -mm tree To: Michal Hocko Cc: akpm@linux-foundation.org, guro@fb.com, linux-mm , rientjes@google.com, shakeelb@google.com, Yafang Shao References: <20200131043324.wkArXTf6-%akpm@linux-foundation.org> <20200417152637.GQ26707@dhcp22.suse.cz> <68371d79-dfae-e9b9-38df-dbb916607a82@i-love.sakura.ne.jp> <20200420073305.GD27314@dhcp22.suse.cz> <041d4158-f3dc-a5b5-546e-dd3f71f67b5f@i-love.sakura.ne.jp> <20200422065950.GA30312@dhcp22.suse.cz> From: Tetsuo Handa Message-ID: <0aa5e490-c5b8-dc5c-334e-9a8d37da215c@i-love.sakura.ne.jp> Date: Thu, 23 Apr 2020 14:34:53 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200422065950.GA30312@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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. 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.