linux-kernel - Re: [PATCH 3/4] tracing, page-allocator: Add trace event for page traffic related to the buddy lists

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090805094346.GC21950@csn.ul.ie>
Date:	Wed, 5 Aug 2009 10:43:46 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Larry Woodman <lwoodman@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>, riel@...hat.com,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [PATCH 3/4] tracing, page-allocator: Add trace event for page
	traffic related to the buddy lists

On Wed, Aug 05, 2009 at 06:24:40PM +0900, KOSAKI Motohiro wrote:
> > The page allocation trace event reports that a page was successfully allocated
> > but it does not specify where it came from. When analysing performance,
> > it can be important to distinguish between pages coming from the per-cpu
> > allocator and pages coming from the buddy lists as the latter requires the
> > zone lock to the taken and more data structures to be examined.
> > 
> > This patch adds a trace event for __rmqueue reporting when a page is being
> > allocated from the buddy lists. It distinguishes between being called
> > to refill the per-cpu lists or whether it is a high-order allocation.
> > Similarly, this patch adds an event to catch when the PCP lists are being
> > drained a little and pages are going back to the buddy lists.
> > 
> > This is trickier to draw conclusions from but high activity on those
> > events could explain why there were a large number of cache misses on a
> > page-allocator-intensive workload. The coalescing and splitting of buddies
> > involves a lot of writing of page metadata and cache line bounces not to
> > mention the acquisition of an interrupt-safe lock necessary to enter this
> > path.
> > 
> > Signed-off-by: Mel Gorman <mel@....ul.ie>
> > Acked-by: Rik van Riel <riel@...hat.com>
> > ---
> >  include/trace/events/kmem.h |   54 +++++++++++++++++++++++++++++++++++++++++++
> >  mm/page_alloc.c             |    2 +
> >  2 files changed, 56 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> > index 0b4002e..3be3df3 100644
> > --- a/include/trace/events/kmem.h
> > +++ b/include/trace/events/kmem.h
> > @@ -311,6 +311,60 @@ TRACE_EVENT(mm_page_alloc,
> >  		show_gfp_flags(__entry->gfp_flags))
> >  );
> >  
> > +TRACE_EVENT(mm_page_alloc_zone_locked,
> > +
> > +	TP_PROTO(const void *page, unsigned int order,
> > +				int migratetype, int percpu_refill),
> > +
> > +	TP_ARGS(page, order, migratetype, percpu_refill),
> > +
> > +	TP_STRUCT__entry(
> > +		__field(	const void *,	page		)
> > +		__field(	unsigned int,	order		)
> > +		__field(	int,		migratetype	)
> > +		__field(	int,		percpu_refill	)
> > +	),
> > +
> > +	TP_fast_assign(
> > +		__entry->page		= page;
> > +		__entry->order		= order;
> > +		__entry->migratetype	= migratetype;
> > +		__entry->percpu_refill	= percpu_refill;
> > +	),
> > +
> > +	TP_printk("page=%p pfn=%lu order=%u migratetype=%d percpu_refill=%d",
> > +		__entry->page,
> > +		page_to_pfn((struct page *)__entry->page),
> > +		__entry->order,
> > +		__entry->migratetype,
> > +		__entry->percpu_refill)
> > +);
> > +
> > +TRACE_EVENT(mm_page_pcpu_drain,
> > +
> > +	TP_PROTO(const void *page, int order, int migratetype),
> > +
> > +	TP_ARGS(page, order, migratetype),
> > +
> > +	TP_STRUCT__entry(
> > +		__field(	const void *,	page		)
> > +		__field(	int,		order		)
> > +		__field(	int,		migratetype	)
> > +	),
> > +
> > +	TP_fast_assign(
> > +		__entry->page		= page;
> > +		__entry->order		= order;
> > +		__entry->migratetype	= migratetype;
> > +	),
> > +
> > +	TP_printk("page=%p pfn=%lu order=%d migratetype=%d",
> > +		__entry->page,
> > +		page_to_pfn((struct page *)__entry->page),
> > +		__entry->order,
> > +		__entry->migratetype)
> > +);
> > +
> >  TRACE_EVENT(mm_page_alloc_extfrag,
> >  
> >  	TP_PROTO(const void *page,
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index c2c90cd..35b92a9 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -535,6 +535,7 @@ static void free_pages_bulk(struct zone *zone, int count,
> >  		page = list_entry(list->prev, struct page, lru);
> >  		/* have to delete it as __free_one_page list manipulates */
> >  		list_del(&page->lru);
> > +		trace_mm_page_pcpu_drain(page, order, page_private(page));
> 
> pcp refill (trace_mm_page_alloc_zone_locked) logged migratetype, but
> this tracepoint doesn't. why?
> 

It does log migratetype as migratetype is in page_private(page) in this
context.

> 
> >  		__free_one_page(page, zone, order, page_private(page));
> >  	}
> >  	spin_unlock(&zone->lock);
> > @@ -878,6 +879,7 @@ retry_reserve:
> >  		}
> >  	}
> >  
> > +	trace_mm_page_alloc_zone_locked(page, order, migratetype, order == 0);
> >  	return page;
> >  }
> 
> Umm, Can we assume order-0 always mean pcp refill?
> 

Right now, that assumption is accurate. Which callpath ends up here with
order == 0 and it's not a PCP refill?

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/