Path: csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!bofh.it!news.nic.it!robomod From: Michal Hocko Newsgroups: linux.kernel Subject: Re: [PATCH] oom_kill: add option to disable dump_stack() Date: Tue, 27 Oct 2015 09:10:02 +0100 Message-ID: References: X-Original-To: Aristeu Rozanski X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=szYD0tzS+PtBT48KY56JjomlRNrUCONapsCpMgTrwoE=; b=aIlCXuHB7dhtLccy1+IT8ZnTYP1h3tXjYK3FxSuc4ZWSPuzZjv8noLeJP3jzVIYZ1x uyhXh2ZO+DbDuW0BifVnRPsfmKJy6G6UfMSkzrpF6sBPwzJl69n9PG1qJhmJEyJI+PvZ N+tHVFhEzup1vGBw0wKl+OzTJgOKecvfArt38Ikh4R+V+9ZueXYST89KPAF6r8BcfUJ5 s0Zxt+Z4pSaJ8MrG+hRNYYDM2onABQh7u/ceTUHMdrDnpOCTrE/IZf7iWxa7IeamT7Wi MXSyn+q6h8hoA7cnrm13/HxVYQj6BYs9f4W6d3A/XHSrmJ3WkSoA1DHFZilzranZWwN+ /w5g== X-Received: by 10.194.175.100 with SMTP id bz4mr25896239wjc.123.1445933362689; Tue, 27 Oct 2015 01:09:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: robomod@news.nic.it List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Approved: robomod@news.nic.it Lines: 30 Organization: linux.* mail to news gateway X-Original-Cc: linux-kernel@vger.kernel.org, Greg Thelen , Johannes Weiner , linux-mm@kvack.org, cgroups@vger.kernel.org X-Original-Date: Tue, 27 Oct 2015 09:09:21 +0100 X-Original-Message-ID: <20151027080920.GA9891@dhcp22.suse.cz> X-Original-References: <1445634150-27992-1-git-send-email-arozansk@redhat.com> <20151026172012.GC9779@dhcp22.suse.cz> <20151026174048.GP15046@redhat.com> X-Original-Sender: linux-kernel-owner@vger.kernel.org Xref: csiph.com linux.kernel:1256545 On Mon 26-10-15 13:40:49, Aristeu Rozanski wrote: > Hi Michal, > On Mon, Oct 26, 2015 at 06:20:12PM +0100, Michal Hocko wrote: [...] > > Would it make more sense to distinguish different parts of the OOM > > report by loglevel properly? > > pr_err - killed task report > > pr_warning - oom invocation + memory info > > pr_notice - task list > > pr_info - stack trace > > That'd work, yes, but I'd think the stack trace would be pr_debug. At a > point that you suspect the OOM killer isn't doing the right thing picking > up tasks and you need more information. Stack trace should be independent on the oom victim selection because the selection should be as much deterministic as possible - so it should only depend on the memory consumption. I do agree that the exact trace is not very useful for the (maybe) majority of OOM reports. I am trying to remember when it was really useful the last time and have trouble to find an example. So I would tend to agree that pr_debug would me more suitable. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/