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=utf-8
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:   Wed, 25 Dec 2019 08:53:12 -0500
Message-Id: <1806FE86-9508-43BC-8E2F-3620CD243B14@lca.pw>
References: <1577266145.31907.4.camel@mtkswgap22>
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: <1577266145.31907.4.camel@mtkswgap22>
To:     Miles Chen <miles.chen@mediatek.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Dec 25, 2019, at 4:29 AM, Miles Chen <miles.chen@mediatek.com> wrote:
>=20
> For example, we're implementing our iommu driver and there are many
> alloc_pages() in drivers/iommu.
> This approach helps us located some memory leakages in our
> implementation.

Not sure if you have code that can share but I can=E2=80=99t imagine there a=
re many places that would have a single call site in the driver doing alloc_=
pages() over and over again. For example, there is only two alloc_pages() in=
 intel-iommu.c with one is only in the cold path, so even if alloc_pgtable_p=
age() one do leaking, it is still up to there air if your patch will catch i=
t because it may not a single call site and it needs to leak significant amo=
unt of memory to be the greatest consumer where it is just not so realistic.=
 For debugging point of view, IMO it is better to annotate this one alloc_pa=
ges() call when in doubt, so that kmemleak would catch it instead.=