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=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 07804C433E2 for ; Mon, 20 Jul 2020 11:06:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A226D22B4E for ; Mon, 20 Jul 2020 11:06:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A226D22B4E 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 F20E76B0003; Mon, 20 Jul 2020 07:06:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAAC56B0005; Mon, 20 Jul 2020 07:06:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4BE26B0006; Mon, 20 Jul 2020 07:06:41 -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 C02066B0003 for ; Mon, 20 Jul 2020 07:06:41 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 70789D6517 for ; Mon, 20 Jul 2020 11:06:41 +0000 (UTC) X-FDA: 77058176202.20.army71_300506326f24 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 6328A1818E6B8 for ; Mon, 20 Jul 2020 11:06:40 +0000 (UTC) X-HE-Tag: army71_300506326f24 X-Filterd-Recvd-Size: 3060 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jul 2020 11:06:39 +0000 (UTC) Received: from fsav304.sakura.ne.jp (fsav304.sakura.ne.jp [153.120.85.135]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 06KB6QSA074256; Mon, 20 Jul 2020 20:06:26 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav304.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav304.sakura.ne.jp); Mon, 20 Jul 2020 20:06:26 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav304.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 06KB6LNr074128 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2020 20:06:26 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH] mm, oom: show process exiting information in __oom_kill_process() To: Yafang Shao , Michal Hocko Cc: David Rientjes , Andrew Morton , Linux MM References: <1595166795-27587-1-git-send-email-laoar.shao@gmail.com> <20200720071607.GA18535@dhcp22.suse.cz> From: Tetsuo Handa Message-ID: <253332d9-9f8c-d472-0bf4-388b29ecfb96@i-love.sakura.ne.jp> Date: Mon, 20 Jul 2020 20:06:17 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6328A1818E6B8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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/07/20 19:36, Yafang Shao wrote: > On Mon, Jul 20, 2020 at 3:16 PM Michal Hocko wrote: >> I do agree that a silent bail out is not the best thing to do. The above >> message would be more useful if it also explained what the oom killer >> does (or does not): >> >> "OOM victim %d (%s) is already exiting. Skip killing the task\n" >> > > Sure. This path is rarely hit because find_lock_task_mm() in oom_badness() from select_bad_process() in the next round of OOM killer will skip this task. Since we don't wake up the OOM reaper when hitting this path, unless __mmput() for this task itself immediately reclaims memory and updates the statistics counter, we just get two chunks of dump_header() messages and one OOM victim. Current synchronous printk() gives __mmput() some time for reclaiming memory and updating the statistics counter. But when printk() becomes asynchronous, there might be quite small time. People might wonder "why killed message follows immediately after skipped killing message"... Wouldn't the skip message confuse people?