From: Miles Chen <miles.chen@mediatek.com>
To: Qian Cai <cai@lca.pw>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>, <linux-mediatek@lists.infradead.org>,
<wsd_upstream@mediatek.com>
Subject: Re: [PATCH] mm/page_owner: print largest memory consumer when OOM panic occurs
Date: Fri, 27 Dec 2019 15:44:30 +0800 [thread overview]
Message-ID: <1577432670.4248.3.camel@mtkswgap22> (raw)
In-Reply-To: <95CD23C9-D10D-4E6A-BF53-A4C1A4DB281A@lca.pw>
On Thu, 2019-12-26 at 00:53 -0500, Qian Cai wrote:
>
> > On Dec 25, 2019, at 11:01 PM, Miles Chen <miles.chen@mediatek.com> wrote:
> >
> > That is what the patch does -- targeting on the memory leakage which causes an OOM kernel panic, so the greatest consumer information helps (the amount of leakage is big enough to cause an OOM kernel panic)
> >
> > I've posted the number of real problems since 2019/5 I solved by this approach.
>
> The point is in order to make your debugging patch upstream, it has to be general useful. Right now,
> it feels rather situational for me for the reasons given in the previous emails.
It's not complete situation.
I've listed different OOM panic situations in previous email [1]
and what we can do about them with current information.
There are some cases which cannot be covered by current information
easily.
For example: a memory leakage caused by alloc_pages() or vmalloc() with
a large size.
I keep seeing these issues for years and that's why I built this patch.
It's like a missing piece of the puzzle.
To prove that the approach is practical and useful, I have collected
real test cases
under real devices and posted the test result in the commit message.
These are real cases, not my imagination.
[1] https://lkml.org/lkml/2019/12/25/53
thanks again for your comments
Miles
WARNING: multiple messages have this Message-ID (diff)
From: Miles Chen <miles.chen@mediatek.com>
To: Qian Cai <cai@lca.pw>
Cc: Michal Hocko <mhocko@suse.com>,
wsd_upstream@mediatek.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-mediatek@lists.infradead.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm/page_owner: print largest memory consumer when OOM panic occurs
Date: Fri, 27 Dec 2019 15:44:30 +0800 [thread overview]
Message-ID: <1577432670.4248.3.camel@mtkswgap22> (raw)
In-Reply-To: <95CD23C9-D10D-4E6A-BF53-A4C1A4DB281A@lca.pw>
On Thu, 2019-12-26 at 00:53 -0500, Qian Cai wrote:
>
> > On Dec 25, 2019, at 11:01 PM, Miles Chen <miles.chen@mediatek.com> wrote:
> >
> > That is what the patch does -- targeting on the memory leakage which causes an OOM kernel panic, so the greatest consumer information helps (the amount of leakage is big enough to cause an OOM kernel panic)
> >
> > I've posted the number of real problems since 2019/5 I solved by this approach.
>
> The point is in order to make your debugging patch upstream, it has to be general useful. Right now,
> it feels rather situational for me for the reasons given in the previous emails.
It's not complete situation.
I've listed different OOM panic situations in previous email [1]
and what we can do about them with current information.
There are some cases which cannot be covered by current information
easily.
For example: a memory leakage caused by alloc_pages() or vmalloc() with
a large size.
I keep seeing these issues for years and that's why I built this patch.
It's like a missing piece of the puzzle.
To prove that the approach is practical and useful, I have collected
real test cases
under real devices and posted the test result in the commit message.
These are real cases, not my imagination.
[1] https://lkml.org/lkml/2019/12/25/53
thanks again for your comments
Miles
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2019-12-27 7:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1806FE86-9508-43BC-8E2F-3620CD243B14@lca.pw>
2019-12-26 4:01 ` [PATCH] mm/page_owner: print largest memory consumer when OOM panic occurs Miles Chen
2019-12-26 4:01 ` Miles Chen
2019-12-26 5:53 ` Qian Cai
2019-12-26 5:53 ` Qian Cai
2019-12-27 7:44 ` Miles Chen [this message]
2019-12-27 7:44 ` Miles Chen
2019-12-27 13:46 ` Qian Cai
2019-12-27 13:46 ` Qian Cai
2019-12-30 1:30 ` Miles Chen
2019-12-30 1:30 ` Miles Chen
2019-12-30 1:51 ` Qian Cai
2019-12-30 1:51 ` Qian Cai
2019-12-30 3:28 ` Miles Chen
2019-12-30 3:28 ` Miles Chen
2019-12-23 11:33 Miles Chen
2019-12-23 11:33 ` Miles Chen
2019-12-23 12:32 ` Qian Cai
2019-12-23 12:32 ` Qian Cai
2019-12-24 6:45 ` Miles Chen
2019-12-24 6:45 ` Miles Chen
2019-12-24 13:47 ` Qian Cai
2019-12-24 13:47 ` Qian Cai
2019-12-25 9:29 ` Miles Chen
2019-12-25 9:29 ` Miles Chen
2019-12-25 13:53 ` Qian Cai
2019-12-25 13:53 ` Qian Cai
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=1577432670.4248.3.camel@mtkswgap22 \
--to=miles.chen@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=cai@lca.pw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=wsd_upstream@mediatek.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.