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.2 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 3B933C55181 for ; Wed, 22 Apr 2020 06:40:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D96FE2070B for ; Wed, 22 Apr 2020 06:40:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D96FE2070B 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 6B0978E0006; Wed, 22 Apr 2020 02:40:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63CEC8E0005; Wed, 22 Apr 2020 02:40:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 504DC8E0006; Wed, 22 Apr 2020 02:40:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 35E588E0003 for ; Wed, 22 Apr 2020 02:40:49 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E8F748248068 for ; Wed, 22 Apr 2020 06:40:48 +0000 (UTC) X-FDA: 76734542976.04.shoes32_5e5055f71af3c X-HE-Tag: shoes32_5e5055f71af3c X-Filterd-Recvd-Size: 4253 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 06:40:47 +0000 (UTC) Received: from fsav401.sakura.ne.jp (fsav401.sakura.ne.jp [133.242.250.100]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 03M6eM2O024958; Wed, 22 Apr 2020 15:40:22 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav401.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav401.sakura.ne.jp); Wed, 22 Apr 2020 15:40:22 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav401.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 03M6eLYX024952 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2020 15:40:22 +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> From: Tetsuo Handa Message-ID: <041d4158-f3dc-a5b5-546e-dd3f71f67b5f@i-love.sakura.ne.jp> Date: Wed, 22 Apr 2020 15:40:19 +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: <20200420073305.GD27314@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/20 16:33, Michal Hocko wrote: > 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_. This patch does avoid RCU stall problem. > 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. "The potentially long taking printk is not done from the locked oom context" is an improvement (which we can do without waiting for async printk changes). > This is what the async printk will address > AFAIU. No! You are completely wrong!! Async printk CANNOT reduce the amount of the output. Rather, async printk might increase the amount of the output (because it allows printk() users to think as if printk() is so fast). Shifting to a deferrable context (like a workqueue) allows reducing the amount of the output. To shift to a deferrable context, this patch (which maintains state of not-yet-reported OOM victim candidates) is the first step. > > That being said, this is not the first time we are in this discussion > and I find repeating the same thing unproductive. Your repeating refusal is really unproductive.