On Thursday 05 April 2012 23:46:17 David Rientjes wrote: > 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. I haven't tested it with hugepage allocation yet (no hugepage support on ARM) but the code isolating pages for migration remains unchanged so after migration memory we are trying to allocate pages from should end up at least as defragmented as before the patch. Some migrations may turn out to be unnecessary but it doesn't seem as it introduces additional problems with hugepage allocation. Best regards, -- Bartlomiej Zolnierkiewicz Samsung Poland R&D Center -- 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>