Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751879AbaKXDG6 (ORCPT ); Sun, 23 Nov 2014 22:06:58 -0500 Received: from lgeamrelo01.lge.com ([156.147.1.125]:38089 "EHLO lgeamrelo01.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750900AbaKXDG5 (ORCPT ); Sun, 23 Nov 2014 22:06:57 -0500 X-Original-SENDERIP: 10.177.222.213 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Mon, 24 Nov 2014 12:09:52 +0900 From: Joonsoo Kim To: Andrew Morton Cc: Mel Gorman , Johannes Weiner , Minchan Kim , Dave Hansen , Michal Nazarewicz , Jungsoo Son , Ingo Molnar , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 6/7] mm/page_owner: keep track of page owners Message-ID: <20141124030952.GC10828@js1304-P5Q-DELUXE> References: <1416557646-21755-1-git-send-email-iamjoonsoo.kim@lge.com> <1416557646-21755-7-git-send-email-iamjoonsoo.kim@lge.com> <20141121153832.a9bd6f8b765608cd1c1959a3@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141121153832.a9bd6f8b765608cd1c1959a3@linux-foundation.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 21, 2014 at 03:38:32PM -0800, Andrew Morton wrote: > On Fri, 21 Nov 2014 17:14:05 +0900 Joonsoo Kim 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/