On Fri, Nov 21, 2014 at 03:38:32PM -0800, Andrew Morton wrote: > On Fri, 21 Nov 2014 17:14:05 +0900 Joonsoo Kim <iamjoonsoo....@lge.com> wrote: > > > This is the page owner tracking code which is introduced > > so far ago. It is resident on Andrew's tree, though, nobody > > tried to upstream so it remain as is. Our company uses this feature > > actively to debug memory leak or to find a memory hogger so > > I decide to upstream this feature. > > > > This functionality help us to know who allocates the page. > > When allocating a page, we store some information about > > allocation in extra memory. Later, if we need to know > > status of all pages, we can get and analyze it from this stored > > information. > > > > In previous version of this feature, extra memory is statically defined > > in struct page, but, in this version, extra memory is allocated outside > > of struct page. It enables us to turn on/off this feature at boottime > > without considerable memory waste. > > > > Although we already have tracepoint for tracing page allocation/free, > > using it to analyze page owner is rather complex. We need to enlarge > > the trace buffer for preventing overlapping until userspace program > > launched. And, launched program continually dump out the trace buffer > > for later analysis and it would change system behaviour with more > > possibility rather than just keeping it in memory, so bad for debug. > > > > Moreover, we can use page_owner feature further for various purposes. > > For example, we can use it for fragmentation statistics implemented in > > this patch. And, I also plan to implement some CMA failure debugging > > feature using this interface. > > > > I'd like to give the credit for all developers contributed this feature, > > but, it's not easy because I don't know exact history. Sorry about that. > > Below is people who has "Signed-off-by" in the patches in Andrew's tree. > > > > ... > > > > --- a/Documentation/kernel-parameters.txt > > +++ b/Documentation/kernel-parameters.txt > > @@ -884,6 +884,12 @@ bytes respectively. Such letter suffixes can also be > > entirely omitted. > > MTRR settings. This parameter disables that behavior, > > possibly causing your machine to run very slowly. > > > > + disable_page_owner > > + [KNL] Disable to store the information who requests > > + the page. > > How about "Disable storage of the information about who allocated each > page". > > It seems odd that we have a disable flag. Wouldn't it be less > surprising to disable it by default and only enable if the boot option > is provided?
Okay. Will do. > > What is the overhead of page_owner if it is runtime-disabled, btw? > Will it be feasible for lots of people to just leave it enabled in > config and to only turn it on when they want to use it? That would be > nice. Please add a paragraph on this point to the changelog and the > yet-to-be-written documentation. - Without page owner text data bss dec hex filename 40662 1493 644 42799 a72f mm/page_alloc.o - With page owner text data bss dec hex filename 40892 1493 644 43029 a815 mm/page_alloc.o 1427 24 8 1459 5b3 mm/page_ext.o 2722 50 0 2772 ad4 mm/page_owner.o Roughly, 4 KB code is added in total. No more runtime memory is needed if runtime-disabled. Size of page_alloc.o is 200 bytes bigger than disabled one. Page owner addes two 'if' statements in allocator hotpath and two 'if' statements in coldpath. If runtime-disabled, allocation performance would not be affected by these few unlikely branches. Will write this to yet-to-be-written documentation. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
