Re: [patch 6/12] mm: remove bad_range

[Dave Hansen <haveblue@us.ibm.com>]

On Mon, 2005-11-21 at 10:12 -0500, Nick Piggin wrote:
> )
> X-Fetchmail-Warning: recipient address lkml2@sr71.net didn't match any local name
> 
> bad_range is supposed to be a temporary check. It would be a pity to throw
> it out. Make it depend on CONFIG_DEBUG_VM instead.
> 
> CONFIG_HOLES_IN_ZONE systems were relying on this to check pfn_valid in
> the page allocator. Add that to page_is_buddy instead.
> 
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> 
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -81,6 +81,7 @@ int min_free_kbytes = 1024;
>  unsigned long __initdata nr_kernel_pages;
>  unsigned long __initdata nr_all_pages;
>  
> +#ifdef CONFIG_DEBUG_VM
>  static int page_outside_zone_boundaries(struct zone *zone, struct page *page)
>  {
>  	int ret = 0;
> @@ -122,6 +123,13 @@ static int bad_range(struct zone *zone, 
>  	return 0;
>  }
>  
> +#else
> +static inline int bad_range(struct zone *zone, struct page *page)
> +{
> +	return 0;
> +}
> +#endif
> +
>  static void bad_page(const char *function, struct page *page)
...
>  static inline int page_is_buddy(struct page *page, int order)
>  {
> +#ifdef CONFIG_HOLES_IN_ZONE
> +	if (!pfn_valid(page_to_pfn(page)))
> +		return 0;
> +#endif
> +
>         if (PagePrivate(page)           &&
>             (page_order(page) == order) &&
>              page_count(page) == 0)
> @@ -320,17 +334,15 @@ static inline void __free_pages_bulk (st
>  		struct free_area *area;
>  		struct page *buddy;
>  
> -		combined_idx = __find_combined_index(page_idx, order);
>  		buddy = __page_find_buddy(page, page_idx, order);
> -
> -		if (bad_range(zone, buddy))
> -			break;
>  		if (!page_is_buddy(buddy, order))
>  			break;		/* Move the buddy up one level. */

I seem to also remember a case with this bad_range() check was useful
for zones that don't have their boundaries aligned on a MAX_ORDER
boundary.  Would this change break such a zone?  Do we care?

-- Dave

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