On Thu, 5 Apr 2012, Bartlomiej Zolnierkiewicz wrote: > diff --git a/mm/compaction.c b/mm/compaction.c > index bc77135..642c17a 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -115,8 +115,8 @@ static bool suitable_migration_target(struct page *page) > if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE) > return false; > > - /* If the page is a large free page, then allow migration */ > - if (PageBuddy(page) && page_order(page) >= pageblock_order) > + /* If the page is a free page, then allow migration */ > + if (PageBuddy(page)) > return true; > > /* If the block is MIGRATE_MOVABLE, allow migration */ So when we try to allocate a 2M hugepage through the buddy allocator where the pageblock is also 2M, wouldn't this result in a lot of unnecessary migration of memory that may not end up defragmented enough for the allocation to succeed? Sounds like a regression for hugepage allocation. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>