All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Larry Woodman <lwoodman@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	riel@redhat.com, Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH 2/6] tracing, page-allocator: Add trace events for anti-fragmentation falling back to other migratetypes
Date: Fri, 7 Aug 2009 13:02:03 +0200	[thread overview]
Message-ID: <20090807110203.GC24916@elte.hu> (raw)
In-Reply-To: <20090807105732.GB18134@csn.ul.ie>


* Mel Gorman <mel@csn.ul.ie> wrote:

> On Fri, Aug 07, 2009 at 10:02:49AM +0200, Ingo Molnar wrote:
> > 
> > * Mel Gorman <mel@csn.ul.ie> wrote:
> > 
> > > +++ b/mm/page_alloc.c
> > > @@ -839,6 +839,12 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
> > >  							start_migratetype);
> > >  
> > >  			expand(zone, page, order, current_order, area, migratetype);
> > > +
> > > +			trace_mm_page_alloc_extfrag(page, order, current_order,
> > > +				start_migratetype, migratetype,
> > > +				current_order < pageblock_order,
> > > +				migratetype == start_migratetype);
> > 
> > This tracepoint too should be optimized some more:
> > 
> >  - pageblock_order can be passed down verbatim instead of the 
> >    'current_order < pageblock_order': it means one comparison less 
> >    in the fast-path, plus it gives more trace information as well.
> > 
> >  - migratetype == start_migratetype check is superfluous as both 
> >    values are already traced. This property can be added to the 
> >    TP_printk() post-processing stage instead, if the pretty-printing 
> >    is desired.
> > 
> 
> I think what you're saying that it's better to handle additional 
> information like this in TP_printk always. That's what I've 
> changed both of these into at least. I didn't even need to pass 
> down pageblock_order because it should be available in the 
> post-processing context from a header.

yeah. I formulated my suggestions in a trace-output-invariant way. 
If some information can be omitted altogether from the trace, the 
better.

> The additional parameters are not being passed down any more and 
> the TP_printk looks like
> 
>         TP_printk("page=%p pfn=%lu alloc_order=%d fallback_order=%d pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d fragmenting=%d change_ownership=%d",
>                 __entry->page,
>                 page_to_pfn(__entry->page),
>                 __entry->alloc_order,
>                 __entry->fallback_order,
>                 pageblock_order,
>                 __entry->alloc_migratetype,
>                 __entry->fallback_migratetype,
>                 __entry->fallback_order < pageblock_order,
>                 __entry->alloc_migratetype == __entry->fallback_migratetype)
> 
> Is that what you meant?

yeah, this looks more compact.

A detail: we might still want to pass in pageblock_order somehow - 
for example 'perf' will get access to the raw binary record but wont 
run the above printk line.

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Larry Woodman <lwoodman@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	riel@redhat.com, Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH 2/6] tracing, page-allocator: Add trace events for anti-fragmentation falling back to other migratetypes
Date: Fri, 7 Aug 2009 13:02:03 +0200	[thread overview]
Message-ID: <20090807110203.GC24916@elte.hu> (raw)
In-Reply-To: <20090807105732.GB18134@csn.ul.ie>


* Mel Gorman <mel@csn.ul.ie> wrote:

> On Fri, Aug 07, 2009 at 10:02:49AM +0200, Ingo Molnar wrote:
> > 
> > * Mel Gorman <mel@csn.ul.ie> wrote:
> > 
> > > +++ b/mm/page_alloc.c
> > > @@ -839,6 +839,12 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
> > >  							start_migratetype);
> > >  
> > >  			expand(zone, page, order, current_order, area, migratetype);
> > > +
> > > +			trace_mm_page_alloc_extfrag(page, order, current_order,
> > > +				start_migratetype, migratetype,
> > > +				current_order < pageblock_order,
> > > +				migratetype == start_migratetype);
> > 
> > This tracepoint too should be optimized some more:
> > 
> >  - pageblock_order can be passed down verbatim instead of the 
> >    'current_order < pageblock_order': it means one comparison less 
> >    in the fast-path, plus it gives more trace information as well.
> > 
> >  - migratetype == start_migratetype check is superfluous as both 
> >    values are already traced. This property can be added to the 
> >    TP_printk() post-processing stage instead, if the pretty-printing 
> >    is desired.
> > 
> 
> I think what you're saying that it's better to handle additional 
> information like this in TP_printk always. That's what I've 
> changed both of these into at least. I didn't even need to pass 
> down pageblock_order because it should be available in the 
> post-processing context from a header.

yeah. I formulated my suggestions in a trace-output-invariant way. 
If some information can be omitted altogether from the trace, the 
better.

> The additional parameters are not being passed down any more and 
> the TP_printk looks like
> 
>         TP_printk("page=%p pfn=%lu alloc_order=%d fallback_order=%d pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d fragmenting=%d change_ownership=%d",
>                 __entry->page,
>                 page_to_pfn(__entry->page),
>                 __entry->alloc_order,
>                 __entry->fallback_order,
>                 pageblock_order,
>                 __entry->alloc_migratetype,
>                 __entry->fallback_migratetype,
>                 __entry->fallback_order < pageblock_order,
>                 __entry->alloc_migratetype == __entry->fallback_migratetype)
> 
> Is that what you meant?

yeah, this looks more compact.

A detail: we might still want to pass in pageblock_order somehow - 
for example 'perf' will get access to the raw binary record but wont 
run the above printk line.

	Ingo

--
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>

  reply	other threads:[~2009-08-07 11:02 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06 16:07 [PATCH 0/4] Add some trace events for the page allocator v4 Mel Gorman
2009-08-06 16:07 ` Mel Gorman
2009-08-06 16:07 ` [PATCH 1/6] tracing, page-allocator: Add trace events for page allocation and page freeing Mel Gorman
2009-08-06 16:07   ` Mel Gorman
2009-08-07  7:50   ` Ingo Molnar
2009-08-07  7:50     ` Ingo Molnar
2009-08-07 10:49     ` Mel Gorman
2009-08-07 10:49       ` Mel Gorman
2009-08-06 16:07 ` [PATCH 2/6] tracing, page-allocator: Add trace events for anti-fragmentation falling back to other migratetypes Mel Gorman
2009-08-06 16:07   ` Mel Gorman
2009-08-07  8:02   ` Ingo Molnar
2009-08-07  8:02     ` Ingo Molnar
2009-08-07 10:57     ` Mel Gorman
2009-08-07 10:57       ` Mel Gorman
2009-08-07 11:02       ` Ingo Molnar [this message]
2009-08-07 11:02         ` Ingo Molnar
2009-08-07 15:26         ` Mel Gorman
2009-08-07 15:26           ` Mel Gorman
2009-08-06 16:07 ` [PATCH 3/6] tracing, page-allocator: Add trace event for page traffic related to the buddy lists Mel Gorman
2009-08-06 16:07   ` Mel Gorman
2009-08-07  7:53   ` Ingo Molnar
2009-08-07  7:53     ` Ingo Molnar
2009-08-07  7:55     ` Ingo Molnar
2009-08-07  7:55       ` Ingo Molnar
2009-08-07 11:09     ` Mel Gorman
2009-08-07 11:09       ` Mel Gorman
2009-08-07  8:04   ` Li Zefan
2009-08-07  8:04     ` Li Zefan
2009-08-07 11:00     ` Mel Gorman
2009-08-07 11:00       ` Mel Gorman
2009-08-06 16:07 ` [PATCH 4/6] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events Mel Gorman
2009-08-06 16:07   ` Mel Gorman
2009-08-06 21:07   ` Li, Ming Chun
2009-08-06 21:07     ` Li, Ming Chun
2009-08-07 11:13     ` Mel Gorman
2009-08-07 11:13       ` Mel Gorman
2009-08-07  8:00   ` Ingo Molnar
2009-08-07  8:00     ` Ingo Molnar
2009-08-07 14:16     ` Mel Gorman
2009-08-07 14:16       ` Mel Gorman
2009-08-06 16:07 ` [PATCH 5/6] tracing, documentation: Add a document describing how to do some performance analysis with tracepoints Mel Gorman
2009-08-06 16:07   ` Mel Gorman
2009-08-07  8:07   ` Ingo Molnar
2009-08-07  8:07     ` Ingo Molnar
2009-08-07 14:25     ` Mel Gorman
2009-08-07 14:25       ` Mel Gorman
2009-08-06 16:07 ` [PATCH 6/6] tracing, documentation: Add a document on the kmem tracepoints Mel Gorman
2009-08-06 16:07   ` Mel Gorman
2009-08-06 16:10 ` [PATCH 0/4] Add some trace events for the page allocator v4 Mel Gorman
2009-08-06 16:10   ` Mel Gorman
  -- strict thread matches above, loose matches on Subject: below --
2009-08-07 17:40 [PATCH 0/6] Add some trace events for the page allocator v5 Mel Gorman
2009-08-07 17:40 ` [PATCH 2/6] tracing, page-allocator: Add trace events for anti-fragmentation falling back to other migratetypes Mel Gorman
2009-08-07 17:40   ` Mel Gorman
2009-08-10 15:41 [PATCH 0/6] Add some trace events for the page allocator v6 Mel Gorman
2009-08-10 15:41 ` [PATCH 2/6] tracing, page-allocator: Add trace events for anti-fragmentation falling back to other migratetypes Mel Gorman
2009-08-10 15:41   ` Mel Gorman

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=20090807110203.GC24916@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lwoodman@redhat.com \
    --cc=mel@csn.ul.ie \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.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.