Messages in this thread | | | Subject | Re: [PATCH] mm,memory_hotplug: Explicitly pass the head to isolate_huge_page | From | Mike Kravetz <> | Date | Tue, 12 Feb 2019 16:13:05 -0800 |
| |
On 2/12/19 6:40 AM, Michal Hocko wrote: > On Tue 12-02-19 14:45:49, Oscar Salvador wrote: >> On Tue, Feb 12, 2019 at 09:33:29AM +0100, Michal Hocko wrote: >>>> >>>> if (PageHuge(page)) { >>>> struct page *head = compound_head(page); >>>> - pfn = page_to_pfn(head) + (1<<compound_order(head)) - 1; >>>> if (compound_order(head) > PFN_SECTION_SHIFT) { >>>> ret = -EBUSY; >>>> break; >>>> } >>> >>> Why are we doing this, btw? >> >> I assume you are referring to: >> >>>> if (compound_order(head) > PFN_SECTION_SHIFT) { >>>> ret = -EBUSY; >>>> break; >>>> } > > yes. > >> I thought it was in case we stumble upon a gigantic page, and commit >> (c8721bbbdd36 mm: memory-hotplug: enable memory hotplug to handle hugepage) >> confirms it. >> >> But I am not really sure if the above condition would still hold on powerpc, >> I wanted to check it but it is a bit more tricky than it is in x86_64 because >> of the different hugetlb sizes. >> Could it be that the above condition is not true, but still the order of that >> hugetlb page goes beyond MAX_ORDER? It is something I have to check.
Well, commit 94310cbcaa3c ("mm/madvise: enable (soft|hard) offline of HugeTLB pages at PGD level") should have allowed migration of gigantic pages. I believe it was added for 16GB pages on powerpc. However, due to subsequent changes I suspsect this no longer works.
> This check doesn't make much sense in principle. Why should we bail out > based on a section size? We are offlining a pfn range. All that we care > about is whether the hugetlb is migrateable.
Yes. Do note that the do_migrate_range is only called from __offline_pages with a start_pfn that was returned by scan_movable_pages. scan_movable_pages has the hugepage_migration_supported check for PageHuge pages. So, it would seem to be redundant to do another check in do_migrate_range.
-- Mike Kravetz
| |