All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: js1304@gmail.com, Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Nazarewicz <mina86@mina86.com>,
	Minchan Kim <minchan@kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH v4 2/2] mm/page_ref: add tracepoint to track down page reference manipulation
Date: Wed, 2 Mar 2016 17:58:26 +0100	[thread overview]
Message-ID: <56D71BB2.5060503@suse.cz> (raw)
In-Reply-To: <1456448282-897-2-git-send-email-iamjoonsoo.kim@lge.com>

On 02/26/2016 01:58 AM, js1304@gmail.com wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> CMA allocation should be guaranteed to succeed by definition, but,
> unfortunately, it would be failed sometimes. It is hard to track down
> the problem, because it is related to page reference manipulation and
> we don't have any facility to analyze it.
>
> This patch adds tracepoints to track down page reference manipulation.
> With it, we can find exact reason of failure and can fix the problem.
> Following is an example of tracepoint output. (note: this example is
> stale version that printing flags as the number. Recent version will
> print it as human readable string.)
>
> Enabling this feature bloat kernel text 30 KB in my configuration.
>
>     text    data     bss     dec     hex filename
> 12127327        2243616 1507328 15878271         f2487f vmlinux_disabled
> 12157208        2258880 1507328 15923416         f2f8d8 vmlinux_enabled
>

That's not bad, and it's even configurable. Thanks for taking the extra 
care about overhead since v1.

> Note that, due to header file dependency problem between mm.h and
> tracepoint.h, this feature has to open code the static key functions
> for tracepoints. Proposed by Steven Rostedt in following link.
>
> https://lkml.org/lkml/2015/12/9/699
>
> v3:
> o Add commit description and code comment why this patch open code
> the static key functions for tracepoints.
> o Notify that example is stale version.
> o Add "depends on TRACEPOINTS".
>
> v2:
> o Use static key of each tracepoints to avoid function call overhead
> when tracepoints are disabled.
> o Print human-readable page flag thanks to newly introduced %pgp option.
> o Add more description to Kconfig.debug.
>
> Acked-by: Michal Nazarewicz <mina86@mina86.com>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

Acked-by: Vlastimil Babka <vbabka@suse.cz>

> +config DEBUG_PAGE_REF
> +	bool "Enable tracepoint to track down page reference manipulation"
> +	depends on DEBUG_KERNEL
> +	depends on TRACEPOINTS
> +	---help---
> +	  This is the feature to add tracepoint for tracking down page reference
> +	  manipulation. This tracking is useful to diagnosis functional failure
> +	  due to migration failure caused by page reference mismatch. Be

OK.

> +	  careful to turn on this feature because it could bloat some kernel
> +	  text. In my configuration, it bloats 30 KB. Although kernel text will
> +	  be bloated, there would be no runtime performance overhead if
> +	  tracepoint isn't enabled thanks to jump label.

I would just write something like:

Enabling this feature adds about 30 KB to the kernel code, but runtime 
performance overhead is virtually none until the tracepoints are 
actually enabled.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: js1304@gmail.com, Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Nazarewicz <mina86@mina86.com>,
	Minchan Kim <minchan@kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH v4 2/2] mm/page_ref: add tracepoint to track down page reference manipulation
Date: Wed, 2 Mar 2016 17:58:26 +0100	[thread overview]
Message-ID: <56D71BB2.5060503@suse.cz> (raw)
In-Reply-To: <1456448282-897-2-git-send-email-iamjoonsoo.kim@lge.com>

On 02/26/2016 01:58 AM, js1304@gmail.com wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> CMA allocation should be guaranteed to succeed by definition, but,
> unfortunately, it would be failed sometimes. It is hard to track down
> the problem, because it is related to page reference manipulation and
> we don't have any facility to analyze it.
>
> This patch adds tracepoints to track down page reference manipulation.
> With it, we can find exact reason of failure and can fix the problem.
> Following is an example of tracepoint output. (note: this example is
> stale version that printing flags as the number. Recent version will
> print it as human readable string.)
>
> Enabling this feature bloat kernel text 30 KB in my configuration.
>
>     text    data     bss     dec     hex filename
> 12127327        2243616 1507328 15878271         f2487f vmlinux_disabled
> 12157208        2258880 1507328 15923416         f2f8d8 vmlinux_enabled
>

That's not bad, and it's even configurable. Thanks for taking the extra 
care about overhead since v1.

> Note that, due to header file dependency problem between mm.h and
> tracepoint.h, this feature has to open code the static key functions
> for tracepoints. Proposed by Steven Rostedt in following link.
>
> https://lkml.org/lkml/2015/12/9/699
>
> v3:
> o Add commit description and code comment why this patch open code
> the static key functions for tracepoints.
> o Notify that example is stale version.
> o Add "depends on TRACEPOINTS".
>
> v2:
> o Use static key of each tracepoints to avoid function call overhead
> when tracepoints are disabled.
> o Print human-readable page flag thanks to newly introduced %pgp option.
> o Add more description to Kconfig.debug.
>
> Acked-by: Michal Nazarewicz <mina86@mina86.com>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

Acked-by: Vlastimil Babka <vbabka@suse.cz>

> +config DEBUG_PAGE_REF
> +	bool "Enable tracepoint to track down page reference manipulation"
> +	depends on DEBUG_KERNEL
> +	depends on TRACEPOINTS
> +	---help---
> +	  This is the feature to add tracepoint for tracking down page reference
> +	  manipulation. This tracking is useful to diagnosis functional failure
> +	  due to migration failure caused by page reference mismatch. Be

OK.

> +	  careful to turn on this feature because it could bloat some kernel
> +	  text. In my configuration, it bloats 30 KB. Although kernel text will
> +	  be bloated, there would be no runtime performance overhead if
> +	  tracepoint isn't enabled thanks to jump label.

I would just write something like:

Enabling this feature adds about 30 KB to the kernel code, but runtime 
performance overhead is virtually none until the tracepoints are 
actually enabled.

  parent reply	other threads:[~2016-03-02 16:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26  0:58 [PATCH v4 1/2] mm: introduce page reference manipulation functions js1304
2016-02-26  0:58 ` js1304
2016-02-26  0:58 ` [PATCH v4 2/2] mm/page_ref: add tracepoint to track down page reference manipulation js1304
2016-02-26  0:58   ` js1304
2016-02-26 16:38   ` Steven Rostedt
2016-02-26 16:38     ` Steven Rostedt
2016-03-02 16:58   ` Vlastimil Babka [this message]
2016-03-02 16:58     ` Vlastimil Babka
2016-03-03  7:43     ` Joonsoo Kim
2016-03-03  7:43       ` Joonsoo Kim
     [not found]       ` <CAAmzW4NwhSKw432qw0Ry+gi=yGpRU-MtC-zQGL27o+XEawLKrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-04 20:04         ` Andrew Morton
2016-03-04 20:04           ` Andrew Morton
2016-03-04 20:04           ` Andrew Morton
2016-03-07  4:20           ` Joonsoo Kim
2016-03-07  4:20             ` Joonsoo Kim
     [not found] ` <1456448282-897-1-git-send-email-iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org>
2016-03-02 16:44   ` [PATCH v4 1/2] mm: introduce page reference manipulation functions Vlastimil Babka
2016-03-02 16:44     ` Vlastimil Babka
2016-03-02 16:44     ` Vlastimil Babka
     [not found]     ` <56D71860.7050108-AlSwsSmVLrQ@public.gmane.org>
2016-03-03  7:47       ` Joonsoo Kim
2016-03-03  7:47         ` Joonsoo Kim
2016-03-03  7:47         ` Joonsoo Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D71BB2.5060503@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=js1304@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mina86@mina86.com \
    --cc=minchan@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.