[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6fa79f98-3df8-0f64-8284-b1fbb3e424a3@nvidia.com>
Date: Tue, 14 Dec 2021 10:27:46 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Minchan Kim <minchan@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
David Hildenbrand <david@...hat.com>,
linux-mm <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
John Dias <joaodias@...gle.com>
Subject: Re: [RFC] mm: introduce page pinner
On 12/13/21 15:10, Minchan Kim wrote:
>>> @@ -62,6 +62,19 @@ config PAGE_OWNER
>>> If unsure, say N.
>>> +config PAGE_PINNER
>>> + bool "Track page pinner"
>>> + select PAGE_EXTENSION
>>> + depends on DEBUG_KERNEL && TRACEPOINTS
>>> + help
>>> + This keeps track of what call chain is the pinner of a page, may
>>> + help to find contiguos page allocation failure. Even if you include
>>> + this feature in your build, it is disabled by default. You should
>>> + pass "page_pinner=on" to boot parameter in order to enable it. Eats
>>> + a fair amount of memory if enabled.
>>
>>
>> We can do a *lot* better in documenting this, than "a fair bit of
>> memory". How about something more like this (borrowing from the updated
>> commit description):
>>
>> This keeps track of what call chain is the pinner of a page. That may
>> help to debug Contiguous Memory Allocator (CMA) allocation failures.
>
> https://lore.kernel.org/lkml/YbfQJ0eTkkImUQ%2Fx@google.com/
>
> I need to rephrase this one to cover other sites not only CMA since other
> reviewer also want to see the failure from compaction.
> If you are interested in, please chime in in the thread.
>
Actually yes, this feature is potentially a general-purpose tracker of page
pinners. It's not inherently CMA-related. One could use it for other cases, such
as any of the NUMA or HMM migration cases. HMM's migration between CPU and
devices fails if pages are pinned, for example.
thanks,
--
John Hubbard
NVIDIA
Powered by blists - more mailing lists