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

[KOSAKI Motohiro]

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

sorry, my fault.
thanks correct me.



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

you are right.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/