linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Rafael Aquini <aquini@redhat.com>
Cc: linux-mm@kvack.org, Randy Dunlap <rdunlap@xenotime.net>,
	Christoph Lameter <cl@linux-foundation.org>,
	Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
	Rik van Riel <riel@redhat.com>, Josef Bacik <josef@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] oom: add sysctl to enable slab memory dump
Date: Wed, 22 Feb 2012 16:44:58 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1202221640420.14213@chino.kir.corp.google.com> (raw)
In-Reply-To: <20120222115320.GA3107@x61.redhat.com>

On Wed, 22 Feb 2012, Rafael Aquini wrote:

> Adds a new sysctl, 'oom_dump_slabs', that enables the kernel to produce a
> dump of all eligible system slab caches when performing an OOM-killing.
> Information includes per cache active objects, total objects, object size,
> cache name and cache size.
> 
> The eligibility for being reported is given by an auxiliary sysctl,
> 'oom_dump_slabs_ratio', which express (in percentage) the memory committed
> ratio between a particular cache size and the total slab size.
> 
> This, alongside with all other data dumped in OOM events, is very helpful
> information in diagnosing why there was an OOM condition specially when
> kernel code is under investigation.
> 

I don't like this because it duplicates what is given by /proc/slabinfo 
that can easily be read at the time of oom and is unnecessary to dump to 
the kernel log.  We display the meminfo (which includes the amount of 
slab, just not broken down by cache) because it's absolutely necessary to 
understand why the oom was triggered.  The tasklist dump is allowed 
because it's difficult to attain all that information easily and to 
determine which threads are eligible in the oom context (global, memcg, 
cpuset, mempolicy) so they matter to the oom condition.  The per-cache 
slabinfo fits neither of that criteria and just duplicates code in the 
slab allocators that is attainable elsewhere.

I think this also gives another usecase for a possible /dev/mem_notify in 
the future: userspace could easily poll on an eventfd and wait for an oom 
to occur and then cat /proc/slabinfo to attain all this.  In other words, 
if we had this functionality (which I think we undoubtedly will in the 
future), this patch would be obsoleted.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2012-02-23  0:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-22 11:53 Rafael Aquini
2012-02-22 13:17 ` Pekka Enberg
2012-02-22 16:04   ` Rafael Aquini
2012-02-22 13:55 ` Christoph Lameter
2012-02-22 16:14   ` Rafael Aquini
2012-02-22 16:29     ` Christoph Lameter
2012-02-23  0:44 ` David Rientjes [this message]
2012-02-23 15:02   ` Josef Bacik
2012-02-23 23:09     ` David Rientjes
2012-02-24 15:10       ` Josef Bacik
2012-02-24 21:45         ` David Rientjes
2012-02-24 21:52           ` Pekka Enberg
2012-02-24 23:51             ` David Rientjes
2012-02-23 15:22   ` Rafael Aquini
2012-02-23 16:03     ` Pekka Enberg
2012-02-23 23:17     ` David Rientjes
2012-02-24  6:57       ` Pekka Enberg
2012-02-24 10:03         ` David Rientjes
2012-02-24 10:05           ` Pekka Enberg
2012-02-24 10:38             ` Rafael Aquini
2012-02-29  3:39             ` Rafael Aquini

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=alpine.DEB.2.00.1202221640420.14213@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=aquini@redhat.com \
    --cc=cl@linux-foundation.org \
    --cc=josef@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpm@selenic.com \
    --cc=penberg@kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=riel@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox