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 1C0C6C2BA19 for ; Fri, 24 Apr 2020 01:17:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 989902074F for ; Fri, 24 Apr 2020 01:17:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 989902074F 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 2B99D8E0005; Thu, 23 Apr 2020 21:17:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 26A038E0003; Thu, 23 Apr 2020 21:17:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1587D8E0005; Thu, 23 Apr 2020 21:17:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id F3B4A8E0003 for ; Thu, 23 Apr 2020 21:17:07 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B022240FE for ; Fri, 24 Apr 2020 01:17:07 +0000 (UTC) X-FDA: 76740984894.08.skate13_3eacaa11da40 X-HE-Tag: skate13_3eacaa11da40 X-Filterd-Recvd-Size: 3858 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Apr 2020 01:17:06 +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 03O1GM0x029218; Fri, 24 Apr 2020 10:16: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); Fri, 24 Apr 2020 10:16: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 03O1GLwZ029208 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2020 10:16: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: Yafang Shao Cc: Michal Hocko , Andrew Morton , Roman Gushchin , linux-mm , David Rientjes , Shakeel Butt , Sergey Senozhatsky , Petr Mladek , Steven Rostedt References: <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> <0aa5e490-c5b8-dc5c-334e-9a8d37da215c@i-love.sakura.ne.jp> <20200423073438.GC4206@dhcp22.suse.cz> <20200423110707.GD4206@dhcp22.suse.cz> From: Tetsuo Handa Message-ID: Date: Fri, 24 Apr 2020 10:16: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: 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/24 9:56, Yafang Shao wrote: > I suggest to set KERN_NO_CONSOLES by default but the user can tune it > back to the original behavior. Yes, I'd like to set KERN_NO_CONSOLES by default. > I'm not a fan of sysctl, but if there's no better chioce, enhancing > vm.oom_dump_tasks seems a possible solution. I don't think vm.oom_dump_tasks is the right variable to enhance. We can allow users to suppress not only dump_tasks() output but also e.g. dump_stack() / show_mem() output, for OOM-killer messages and memory allocation failure messages can take long time (if printed to consoles) is an unhappy thing for OOM context and atomic context. Since Dmitry Safonov is working on adding loglevel argument to show_stack(), we will be able to control dump_stack() in near future. I think that we should introduce a new sysctl variable under vm directory in order to implement bitmask for "which OOM and memory allocation failure related messages should be printed to consoles". I think that there is no need to print to consoles (i.e. saving to log files via userspace syslog daemon is sufficient) for most systems.