From: Michal Hocko <mhocko@kernel.org>
To: Yang Shi <yang.s@alibaba-inc.com>
Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com,
iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2 v4] oom: capture unreclaimable slab info in oom message when kernel panic
Date: Mon, 25 Sep 2017 16:23:52 +0200 [thread overview]
Message-ID: <20170925142352.havlx6ikheanqyhj@dhcp22.suse.cz> (raw)
In-Reply-To: <1505947132-4363-1-git-send-email-yang.s@alibaba-inc.com>
On Thu 21-09-17 06:38:50, Yang Shi wrote:
> Recently we ran into a oom issue, kernel panic due to no killable process.
> The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump doesn't capture vmcore due to some reason.
>
> So, it may sound better to capture unreclaimable slab info in oom message when kernel panic to aid trouble shooting and cover the corner case.
> Since kernel already panic, so capturing more information sounds worthy and doesn't bother normal oom killer.
>
> With the patchset, tools/vm/slabinfo has a new option, "-U", to show unreclaimable slab only.
>
> And, oom will print all non zero (num_objs * size != 0) unreclaimable slabs in oom killer message.
Well, I do undestand that this _might_ be useful but it also might
generates a _lot_ of output. The oom report can be quite verbose already
so is this something we want to have enabled by default?
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Yang Shi <yang.s@alibaba-inc.com>
Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com,
iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2 v4] oom: capture unreclaimable slab info in oom message when kernel panic
Date: Mon, 25 Sep 2017 16:23:52 +0200 [thread overview]
Message-ID: <20170925142352.havlx6ikheanqyhj@dhcp22.suse.cz> (raw)
In-Reply-To: <1505947132-4363-1-git-send-email-yang.s@alibaba-inc.com>
On Thu 21-09-17 06:38:50, Yang Shi wrote:
> Recently we ran into a oom issue, kernel panic due to no killable process.
> The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump doesn't capture vmcore due to some reason.
>
> So, it may sound better to capture unreclaimable slab info in oom message when kernel panic to aid trouble shooting and cover the corner case.
> Since kernel already panic, so capturing more information sounds worthy and doesn't bother normal oom killer.
>
> With the patchset, tools/vm/slabinfo has a new option, "-U", to show unreclaimable slab only.
>
> And, oom will print all non zero (num_objs * size != 0) unreclaimable slabs in oom killer message.
Well, I do undestand that this _might_ be useful but it also might
generates a _lot_ of output. The oom report can be quite verbose already
so is this something we want to have enabled by default?
--
Michal Hocko
SUSE Labs
--
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>
next prev parent reply other threads:[~2017-09-25 14:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 22:38 [PATCH 0/2 v4] oom: capture unreclaimable slab info in oom message when kernel panic Yang Shi
2017-09-20 22:38 ` Yang Shi
2017-09-20 22:38 ` [PATCH 1/2] tools: slabinfo: add "-U" option to show unreclaimable slabs only Yang Shi
2017-09-20 22:38 ` Yang Shi
2017-09-20 22:38 ` [PATCH 2/2] mm: oom: show unreclaimable slab info when kernel panic Yang Shi
2017-09-20 22:38 ` Yang Shi
2017-09-21 8:23 ` David Rientjes
2017-09-21 8:23 ` David Rientjes
2017-09-21 17:51 ` Yang Shi
2017-09-21 17:51 ` Yang Shi
2017-09-25 14:23 ` Michal Hocko [this message]
2017-09-25 14:23 ` [PATCH 0/2 v4] oom: capture unreclaimable slab info in oom message " Michal Hocko
2017-09-25 15:55 ` Yang Shi
2017-09-25 15:55 ` Yang Shi
2017-09-25 20:32 ` Michal Hocko
2017-09-25 20:32 ` Michal Hocko
2017-09-25 21:52 ` Yang Shi
2017-09-25 21:52 ` Yang Shi
2017-09-26 7:56 ` Michal Hocko
2017-09-26 7:56 ` 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=20170925142352.havlx6ikheanqyhj@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=yang.s@alibaba-inc.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.