linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Yang Shi" <yang.s@alibaba-inc.com>
To: cl@linux.com, penberg@kernel.org, rientjes@google.com,
	iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
	mhocko@kernel.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3 v8] oom: capture unreclaimable slab info in oom message
Date: Wed, 04 Oct 2017 02:10:38 +0800	[thread overview]
Message-ID: <5b652442-d737-656d-2f54-ce69664a946b@alibaba-inc.com> (raw)
In-Reply-To: <1507053977-116952-1-git-send-email-yang.s@alibaba-inc.com>

This round should be v9. Sorry for the typo.

Yang


On 10/3/17 11:06 AM, 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.
> 
> For details, please see the commit log for each commit.
> 
> Changelog v8 a??> 9:
> * Adopted Tetsuoa??s suggestion to protect global slab list traverse with mutex_trylock() to prevent from sleeping. Without the mutex acquired unreclaimable slbas will not be dumped.
> * Adopted the suggestion from Christoph to dump CONFIG_SLABINFO since it is pointless to keep it.
> * Rebased to 4.13-rc3
> 
> Changelog v7 a??> v8:
> * Adopted Michala??s suggestion to dump unreclaim slab info when unreclaimable slabs amount > total user memory. Not only in oom panic path.
> 
> Changelog v6 -> v7:
> * Added unreclaim_slabs_oom_ratio proc knob, unreclaimable slabs info will be dumped when unreclaimable slabs amount : all user memory > the ratio
> 
> Changelog v5 a??> v6:
> * Fixed a checkpatch.pl warning for patch #2
> 
> Changelog v4 a??> v5:
> * Solved the comments from David
> * Build test SLABINFO = n
> 
> Changelog v3 a??> v4:
> * Solved the comments from David
> * Added Davida??s Acked-by in patch 1
> 
> Changelog v2 a??> v3:
> * Show used size and total size of each kmem cache per Davida??s comment
> 
> Changelog v1 a??> v2:
> * Removed the original patch 1 (a??mm: slab: output reclaimable flag in /proc/slabinfoa??) since Christoph suggested it might break the compatibility and /proc/slabinfo is legacy
> * Added Christopha??s Acked-by
> * Removed acquiring slab_mutex per Tetsuoa??s comment
> 
> 
> Yang Shi (3):
>        tools: slabinfo: add "-U" option to show unreclaimable slabs only
>        mm: slabinfo: dump CONFIG_SLABINFO
>        mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
> 
>   init/Kconfig        |  6 ------
>   mm/memcontrol.c     |  2 --
>   mm/oom_kill.c       | 22 ++++++++++++++++++++++
>   mm/slab.c           |  2 --
>   mm/slab.h           |  2 ++
>   mm/slab_common.c    | 35 ++++++++++++++++++++++++++++++++---
>   mm/slub.c           |  2 --
>   tools/vm/slabinfo.c | 11 ++++++++++-
>   8 files changed, 66 insertions(+), 16 deletions(-)
> 

--
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>

      parent reply	other threads:[~2017-10-03 18:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 18:06 Yang Shi
2017-10-03 18:06 ` [PATCH 1/3] tools: slabinfo: add "-U" option to show unreclaimable slabs only Yang Shi
2017-10-03 18:06 ` [PATCH 2/3] mm: slabinfo: dump CONFIG_SLABINFO Yang Shi
2017-10-03 18:06 ` [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory Yang Shi
2017-10-04 14:27   ` Michal Hocko
2017-10-04 17:37     ` Yang Shi
2017-10-04 18:08     ` Yang Shi
2017-10-05  7:57       ` Michal Hocko
2017-10-03 18:10 ` Yang Shi [this message]

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=5b652442-d737-656d-2f54-ce69664a946b@alibaba-inc.com \
    --to=yang.s@alibaba-inc.com \
    --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=mhocko@kernel.org \
    --cc=penberg@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox