Messages in this thread | | | Subject | Re: Major mke2fs slowdown (reproducable, bisected) | From | Andi Kleen <> | Date | Tue, 13 Nov 2007 17:25:09 +0100 |
| |
Alexey Dobriyan <adobriyan@gmail.com> writes: > > +/* Return the page with the lowest PFN in the list */ > +static struct page *min_page(struct list_head *list) > +{ > + unsigned long min_pfn = -1UL; > + struct page *min_page = NULL, *page;; > + > + list_for_each_entry(page, list, lru) { > + unsigned long pfn = page_to_pfn(page); > + if (pfn < min_pfn) { > + min_pfn = pfn; > + min_page = page; > + } > + } > + > + return min_page; > +} > + > /* Remove an element from the buddy allocator from the fallback list */ > static struct page *__rmqueue_fallback(struct zone *zone, int order, > int start_migratetype) > @@ -795,8 +812,11 @@ retry: > if (list_empty(&area->free_list[migratetype])) > continue; > > + /* Bias kernel allocations towards low pfns */ > page = list_entry(area->free_list[migratetype].next, > struct page, lru); > + if (unlikely(start_migratetype != MIGRATE_MOVABLE)) > + page = min_page(&area->free_list[migratetype]);
Do I misread this, or does it really turn the O(1) buddy allocation into a "search whole free list" algorithm? Even as fallback that looks like a quite extreme thing to do.
-Andi - 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/
| |