From: Jianguo Wu <wujianguo@huawei.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Rik van Riel <riel@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [question] how to figure out OOM reason? should dump slab/vmalloc info when OOM?
Date: Tue, 21 Jan 2014 20:40:00 +0800 [thread overview]
Message-ID: <52DE6AA0.1000801@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1401202130590.21729@chino.kir.corp.google.com>
On 2014/1/21 13:34, David Rientjes wrote:
> On Mon, 20 Jan 2014, Jianguo Wu wrote:
>
>> When OOM happen, will dump buddy free areas info, hugetlb pages info,
>> memory state of all eligible tasks, per-cpu memory info.
>> But do not dump slab/vmalloc info, sometime, it's not enough to figure out the
>> reason OOM happened.
>>
>> So, my questions are:
>> 1. Should dump slab/vmalloc info when OOM happen? Though we can get these from proc file,
>> but usually we do not monitor the logs and check proc file immediately when OOM happened.
>>
>
Hi David,
Thank you for your patience to answer!
> The problem is that slabinfo becomes excessively verbose and dumping it
> all to the kernel log often times causes important messages to be lost.
> This is why we control things like the tasklist dump with a VM sysctl. It
> would be possible to dump, say, the top ten slab caches with the highest
> memory usage, but it will only be helpful for slab leaks. Typically there
> are better debugging tools available than analyzing the kernel log; if you
> see unusually high slab memory in the meminfo dump, you can enable it.
>
But, when OOM has happened, we can only use kernel log, slab/vmalloc info from proc
is stale. Maybe we can dump slab/vmalloc with a VM sysctl, and only top 10/20 entrys?
Thanks.
>> 2. /proc/$pid/smaps and pagecache info also helpful when OOM, should also be dumped?
>>
>
> Also very verbose and would cause important messages to be lost, we try to
> avoid spamming the kernel log with all of this information as much as
> possible.
>
>> 3. Without these info, usually how to figure out OOM reason?
>>
>
> Analyze the memory usage in the meminfo and determine what is unusually
> high; if it's mostly anonymous memory, you can usually correlate it back
> to a high rss for a process in the tasklist that you didn't suspect to be
> using that much memory, for example.
>
>
--
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: Jianguo Wu <wujianguo@huawei.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Rik van Riel <riel@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [question] how to figure out OOM reason? should dump slab/vmalloc info when OOM?
Date: Tue, 21 Jan 2014 20:40:00 +0800 [thread overview]
Message-ID: <52DE6AA0.1000801@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1401202130590.21729@chino.kir.corp.google.com>
On 2014/1/21 13:34, David Rientjes wrote:
> On Mon, 20 Jan 2014, Jianguo Wu wrote:
>
>> When OOM happen, will dump buddy free areas info, hugetlb pages info,
>> memory state of all eligible tasks, per-cpu memory info.
>> But do not dump slab/vmalloc info, sometime, it's not enough to figure out the
>> reason OOM happened.
>>
>> So, my questions are:
>> 1. Should dump slab/vmalloc info when OOM happen? Though we can get these from proc file,
>> but usually we do not monitor the logs and check proc file immediately when OOM happened.
>>
>
Hi David,
Thank you for your patience to answer!
> The problem is that slabinfo becomes excessively verbose and dumping it
> all to the kernel log often times causes important messages to be lost.
> This is why we control things like the tasklist dump with a VM sysctl. It
> would be possible to dump, say, the top ten slab caches with the highest
> memory usage, but it will only be helpful for slab leaks. Typically there
> are better debugging tools available than analyzing the kernel log; if you
> see unusually high slab memory in the meminfo dump, you can enable it.
>
But, when OOM has happened, we can only use kernel log, slab/vmalloc info from proc
is stale. Maybe we can dump slab/vmalloc with a VM sysctl, and only top 10/20 entrys?
Thanks.
>> 2. /proc/$pid/smaps and pagecache info also helpful when OOM, should also be dumped?
>>
>
> Also very verbose and would cause important messages to be lost, we try to
> avoid spamming the kernel log with all of this information as much as
> possible.
>
>> 3. Without these info, usually how to figure out OOM reason?
>>
>
> Analyze the memory usage in the meminfo and determine what is unusually
> high; if it's mostly anonymous memory, you can usually correlate it back
> to a high rss for a process in the tasklist that you didn't suspect to be
> using that much memory, for example.
>
>
next prev parent reply other threads:[~2014-01-21 12:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 10:36 [question] how to figure out OOM reason? should dump slab/vmalloc info when OOM? Jianguo Wu
2014-01-20 10:36 ` Jianguo Wu
2014-01-21 5:34 ` David Rientjes
2014-01-21 5:34 ` David Rientjes
2014-01-21 12:40 ` Jianguo Wu [this message]
2014-01-21 12:40 ` Jianguo Wu
2014-01-21 20:41 ` David Rientjes
2014-01-21 20:41 ` David Rientjes
2014-02-11 4:06 ` Jianguo Wu
2014-02-11 4:06 ` Jianguo Wu
2014-02-12 0:28 ` David Rientjes
2014-02-12 0:28 ` David Rientjes
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=52DE6AA0.1000801@huawei.com \
--to=wujianguo@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=rientjes@google.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 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.