Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] mm/page_owner: print largest memory consumer when OOM panic occurs
Date:   Thu, 26 Dec 2019 00:53:27 -0500
Message-Id: <95CD23C9-D10D-4E6A-BF53-A4C1A4DB281A@lca.pw>
References: <20191226040114.8123-1-miles.chen@mediatek.com>
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
In-Reply-To: <20191226040114.8123-1-miles.chen@mediatek.com>
To:     Miles Chen <miles.chen@mediatek.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Dec 25, 2019, at 11:01 PM, Miles Chen <miles.chen@mediatek.com> wrote:
>=20
> That is what the patch does -- targeting on the memory leakage which cause=
s an OOM kernel panic, so the greatest consumer information helps (the amoun=
t of leakage is big enough to cause an OOM kernel panic)
>=20
> I've posted the number of real problems since 2019/5 I solved by this appr=
oach.

The point is in order to make your debugging patch upstream, it has to be ge=
neral useful. Right now, it feels rather situational for me for the reasons g=
iven in the previous emails.=