Hi Johannes,
I think this should fix the inefficiency. What you think?
Still it shouldn't be able to fix any instability. And I'm afraid
it'll hide bugs. Nevertheless this is the correct behavior, it's
pointless to migrate hugepages around even if it is supposed to work
fine and needed by move_pages.
I'm going to commit it to my tree after some testing.
Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
---
diff --git a/mm/compaction.c b/mm/compaction.c
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -265,10 +265,34 @@ static unsigned long isolate_migratepage
if (PageBuddy(page))
continue;
+ /*
+ * __split_huge_page_refcount() runs with the
+ * zone->lru_lock held so PG_head can't go away from
+ * under us. We use PageTransCompound because
+ * PageTransHuge would VM_BUG_ON if it runs into some
+ * random tail page that doesn't belong to transparent
+ * hugepage subsystem during the pfn scan.
+ */
+ if (PageTransCompound(page)) {
+ low_pfn += (1 << page_order(page)) - 1;
+ continue;
+ }
+
/* Try isolate the page */
if (__isolate_lru_page(page, ISOLATE_BOTH, 0) != 0)
continue;
+ /*
+ * khugepaged cannot generate an hugepage queued into
+ * the LRU before __isolate_lru_page runs, because
+ * it has to take the zone->lru_lock first in order to
+ * set PageLRU onto the hugepage. And PageHead is always
+ * set by the buddy allocator before returning the hugepage
+ * to khugepaged and in turn before taking the lru_lock
+ * to set PageLRU.
+ */
+ BUG_ON(PageTransCompound(page));
+
/* Successfully isolated */
del_page_from_lru_list(zone, page, page_lru(page));
list_add(&page->lru, migratelist);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>