Re: [PATCH 19/22] Update NR_FREE_PAGES only as necessary
From: Mel Gorman
Date: Fri Apr 24 2009 - 09:07:01 EST
On Thu, Apr 23, 2009 at 04:06:10PM -0700, Andrew Morton wrote:
> On Wed, 22 Apr 2009 14:53:24 +0100
> Mel Gorman <mel@xxxxxxxxx> wrote:
>
> > When pages are being freed to the buddy allocator, the zone
> > NR_FREE_PAGES counter must be updated. In the case of bulk per-cpu page
> > freeing, it's updated once per page. This retouches cache lines more
> > than necessary. Update the counters one per per-cpu bulk free.
> >
> > ...
> >
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -460,7 +460,6 @@ static inline void __free_one_page(struct page *page,
> > int migratetype)
> > {
> > unsigned long page_idx;
> > - int order_size = 1 << order;
> >
> > if (unlikely(PageCompound(page)))
> > if (unlikely(destroy_compound_page(page, order)))
> > @@ -470,10 +469,9 @@ static inline void __free_one_page(struct page *page,
> >
> > page_idx = page_to_pfn(page) & ((1 << MAX_ORDER) - 1);
> >
> > - VM_BUG_ON(page_idx & (order_size - 1));
> > + VM_BUG_ON(page_idx & ((1 << order) - 1));
> > VM_BUG_ON(bad_range(zone, page));
> >
>
> <head spins>
>
> Is this all a slow and obscure way of doing
>
> VM_BUG_ON(order > MAX_ORDER);
>
> ?
Nope.
>
> If not, what _is_ it asserting?
>
That the page is properly placed. The start of the page being freed has to
be size-of-page-aligned. If it isn't the calculation that works out where
the buddy is will break.
--
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/