All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
To: Aristeu Rozanski <arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] oom_kill: add option to disable dump_stack()
Date: Mon, 26 Oct 2015 12:01:11 -0400	[thread overview]
Message-ID: <20151026160111.GA2214@cmpxchg.org> (raw)
In-Reply-To: <1445634150-27992-1-git-send-email-arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Fri, Oct 23, 2015 at 05:02:30PM -0400, Aristeu Rozanski wrote:
> One of the largest chunks of log messages in a OOM is from dump_stack() and in
> some cases it isn't even necessary to figure out what's going on. In
> systems with multiple tenants/containers with limited resources each
> OOMs can be way more frequent and being able to reduce the amount of log
> output for each situation is useful.
> 
> This patch adds a sysctl to allow disabling dump_stack() during an OOM while
> keeping the default to behave the same way it behaves today.
> 
> Cc: Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
> Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
> Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Aristeu Rozanski <arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

I think this makes sense.

The high volume log output is not just annoying, we have also had
reports from people whose machines locked up as they tried to log
hundreds of containers through a low-bandwidth serial console.

Could you include sample output of before and after in the changelog
to provide an immediate comparison on what we are saving?

Should we make the knob specific to the stack dump or should it be
more generic, so that we could potentially save even more output?

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Aristeu Rozanski <arozansk@redhat.com>
Cc: linux-kernel@vger.kernel.org, Greg Thelen <gthelen@google.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org
Subject: Re: [PATCH] oom_kill: add option to disable dump_stack()
Date: Mon, 26 Oct 2015 12:01:11 -0400	[thread overview]
Message-ID: <20151026160111.GA2214@cmpxchg.org> (raw)
In-Reply-To: <1445634150-27992-1-git-send-email-arozansk@redhat.com>

On Fri, Oct 23, 2015 at 05:02:30PM -0400, Aristeu Rozanski wrote:
> One of the largest chunks of log messages in a OOM is from dump_stack() and in
> some cases it isn't even necessary to figure out what's going on. In
> systems with multiple tenants/containers with limited resources each
> OOMs can be way more frequent and being able to reduce the amount of log
> output for each situation is useful.
> 
> This patch adds a sysctl to allow disabling dump_stack() during an OOM while
> keeping the default to behave the same way it behaves today.
> 
> Cc: Greg Thelen <gthelen@google.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: linux-mm@kvack.org
> Cc: cgroups@vger.kernel.org
> Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>

I think this makes sense.

The high volume log output is not just annoying, we have also had
reports from people whose machines locked up as they tried to log
hundreds of containers through a low-bandwidth serial console.

Could you include sample output of before and after in the changelog
to provide an immediate comparison on what we are saving?

Should we make the knob specific to the stack dump or should it be
more generic, so that we could potentially save even more output?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Aristeu Rozanski <arozansk@redhat.com>
Cc: linux-kernel@vger.kernel.org, Greg Thelen <gthelen@google.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org
Subject: Re: [PATCH] oom_kill: add option to disable dump_stack()
Date: Mon, 26 Oct 2015 12:01:11 -0400	[thread overview]
Message-ID: <20151026160111.GA2214@cmpxchg.org> (raw)
In-Reply-To: <1445634150-27992-1-git-send-email-arozansk@redhat.com>

On Fri, Oct 23, 2015 at 05:02:30PM -0400, Aristeu Rozanski wrote:
> One of the largest chunks of log messages in a OOM is from dump_stack() and in
> some cases it isn't even necessary to figure out what's going on. In
> systems with multiple tenants/containers with limited resources each
> OOMs can be way more frequent and being able to reduce the amount of log
> output for each situation is useful.
> 
> This patch adds a sysctl to allow disabling dump_stack() during an OOM while
> keeping the default to behave the same way it behaves today.
> 
> Cc: Greg Thelen <gthelen@google.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: linux-mm@kvack.org
> Cc: cgroups@vger.kernel.org
> Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>

I think this makes sense.

The high volume log output is not just annoying, we have also had
reports from people whose machines locked up as they tried to log
hundreds of containers through a low-bandwidth serial console.

Could you include sample output of before and after in the changelog
to provide an immediate comparison on what we are saving?

Should we make the knob specific to the stack dump or should it be
more generic, so that we could potentially save even more output?

  parent reply	other threads:[~2015-10-26 16:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23 21:02 [PATCH] oom_kill: add option to disable dump_stack() Aristeu Rozanski
2015-10-23 21:02 ` Aristeu Rozanski
     [not found] ` <1445634150-27992-1-git-send-email-arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-10-26 16:01   ` Johannes Weiner [this message]
2015-10-26 16:01     ` Johannes Weiner
2015-10-26 16:01     ` Johannes Weiner
2015-10-26 17:46     ` Aristeu Rozanski
2015-10-26 17:46       ` Aristeu Rozanski
2015-10-26 17:20   ` Michal Hocko
2015-10-26 17:20     ` Michal Hocko
2015-10-26 17:20     ` Michal Hocko
     [not found]     ` <20151026172012.GC9779-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-10-26 17:40       ` Aristeu Rozanski
2015-10-26 17:40         ` Aristeu Rozanski
2015-10-26 17:40         ` Aristeu Rozanski
     [not found]         ` <20151026174048.GP15046-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-10-27  8:09           ` Michal Hocko
2015-10-27  8:09             ` Michal Hocko
2015-10-27  8:09             ` Michal Hocko
     [not found]             ` <20151027080920.GA9891-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-10-27 15:43               ` Aristeu Rozanski
2015-10-27 15:43                 ` Aristeu Rozanski
2015-10-27 15:43                 ` Aristeu Rozanski
     [not found]                 ` <20151027154341.GA14722-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-10-27 16:20                   ` Michal Hocko
2015-10-27 16:20                     ` Michal Hocko
2015-10-27 16:20                     ` Michal Hocko
2015-10-27 17:51                     ` Aristeu Rozanski
2015-10-27 17:51                       ` Aristeu Rozanski
2015-10-28 23:55                       ` David Rientjes
2015-10-28 23:55                         ` David Rientjes
2015-10-26 21:38 ` David Rientjes
2015-10-26 21:38   ` David Rientjes
2015-12-01 23:43 ` Andrew Morton
2015-12-01 23:43   ` Andrew Morton
     [not found]   ` <20151201154353.87e2200b5cd1a99289ce6653-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2015-12-02  0:02     ` David Rientjes
2015-12-02  0:02       ` David Rientjes
2015-12-02  0:02       ` David Rientjes
2015-12-02  8:18     ` Michal Hocko
2015-12-02  8:18       ` Michal Hocko
2015-12-02  8:18       ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151026160111.GA2214@cmpxchg.org \
    --to=hannes-druugvl0lcnafugrpc6u6w@public.gmane.org \
    --cc=arozansk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.