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=-4.0 required=3.0 tests=BAYES_00,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 D710DC433E3 for ; Thu, 16 Jul 2020 12:22:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A0D3C2065F for ; Thu, 16 Jul 2020 12:22:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A0D3C2065F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1EFE26B002F; Thu, 16 Jul 2020 08:22:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 178F38D0001; Thu, 16 Jul 2020 08:22:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0411E6B0031; Thu, 16 Jul 2020 08:22:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) by kanga.kvack.org (Postfix) with ESMTP id E04E16B002F for ; Thu, 16 Jul 2020 08:22:10 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A06F5180AD804 for ; Thu, 16 Jul 2020 12:22:10 +0000 (UTC) X-FDA: 77043851220.17.wool14_291253f26f02 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 0102E180D07B8 for ; Thu, 16 Jul 2020 12:21:54 +0000 (UTC) X-HE-Tag: wool14_291253f26f02 X-Filterd-Recvd-Size: 4921 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jul 2020 12:21:54 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id 22so10105131wmg.1 for ; Thu, 16 Jul 2020 05:21:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1GmOOnkn9yaDm8vG6jD5mhyFrDuqvaceJkd5jro35m4=; b=os9Jlpn1sJq+tgkrkLUZAGVkMu9vXuqVH3KZiKJCCJeHbPxfqPOlrDGLrHL4nUh/6s vRDwulwguYB1C5huwkyf6yrJRMMpbqJZwvcyDqr54aPG0VWpWlLUKlqDg4ijJLU3pMPY zdh2XsQLq3bcdpZgEy90IprgOJLbxokw6772LWeCZt6TJ92MCST/L6dEWnESWMaQa1YJ G2aHRmPcO1G1sgWkzxneqy/TyF+sh35QOLhQBBte12f9FVjH9umMPkkhHBXbvJhAJMAY oRkNlc75FueGdnPJvJ7DVCa74fAHV3kfSE/B7el/zlF2DYSgBS7hsj5yQCY2mtjQhsB/ lgrQ== X-Gm-Message-State: AOAM533jvBZ38bjlNPWBbuewmFNC8hhHd0AwX2aemE4YycZLB80emSS+ Q61JQIAv0yvq+JXTnQn0lQs= X-Google-Smtp-Source: ABdhPJzzCwrF+klLECTzfJJ48aWBVRJwkHYg/S3/LQa5buFNLZsJGcHN+qLIrBeqJwuY+zDk8opCXw== X-Received: by 2002:a1c:5581:: with SMTP id j123mr4026981wmb.75.1594902113304; Thu, 16 Jul 2020 05:21:53 -0700 (PDT) Received: from localhost (ip-37-188-169-187.eurotel.cz. [37.188.169.187]) by smtp.gmail.com with ESMTPSA id 5sm7923403wmk.9.2020.07.16.05.21.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jul 2020 05:21:52 -0700 (PDT) Date: Thu, 16 Jul 2020 14:21:50 +0200 From: Michal Hocko To: Yafang Shao Cc: David Rientjes , Tetsuo Handa , Andrew Morton , Johannes Weiner , Linux MM Subject: Re: [PATCH v2] memcg, oom: check memcg margin for parallel oom Message-ID: <20200716122150.GL31089@dhcp22.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0102E180D07B8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Thu 16-07-20 19:53:12, Yafang Shao wrote: [...] > I'd prefer to put dump_header() behind do_send_sig_info(), for example, > > __oom_kill_process() > do_send_sig_info() > dump_header() <<<< may better put it behind wake_oom_reaper(), but > it may loses some information to dump... > pr_err("%s: Killed process %d (%s)....") > > Because the main goal of OOM is to kill a process to free pages ASAP > to avoid system stall or memcg stall. > We all find that dump_header() may take a long time to finish > especially if there is a slow console, and this long time may cause a > great system stall, so we'd better defer the dump of it. I would be worried that such a memory dump would be very likely not reflecting the actual OOM situation and thus hard to use for analysis. Why? Because the killed oom victim can _usually_ die or the oom reaper can free up a lot of memory very quickly. If we look at it the main part of the report which takes long to dump is dump_tasks because this is potentially a lot of data. I haven't seen show_mem or its memcg counterpart to take a long time. We've discussed how much dump_tasks is really useful for production systems and the general feedback was that it should be enabled by default, though. If the oom report should be misleading then it would be better to not bother at all IMHO. From my experience the memory state is really useful when debugging ooms and having a reasonable snapshot is really important. IIRC Tetsuo was suggesting collecting all the information at the time of the oom and print that snapshot later on but the patch was quite invasive and didn't handle multiple OOMs from different oom domains - especially the dump_task part would need to link all the tasks for different oom contexts. Anyway, I think we are getting off topic here. -- Michal Hocko SUSE Labs