Re: [PATCH v5 05/14] mm, compaction: move pageblock checks up from isolate_migratepages_range()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/30/2014 01:51 AM, David Rientjes wrote:
On Wed, 30 Jul 2014, Kirill A. Shutemov wrote:

Hmm, I'm confused at how that could be true, could you explain what
memory other than thp can return true for PageTransHuge()?

PageTransHuge() will be true for any head of compound page if THP is
enabled compile time: hugetlbfs, slab, whatever.


I was meaning in the context of the patch :)  Since PageLRU is set, that
discounts slab so we're left with thp or hugetlbfs.  Logically, both
should have sizes that are >= the size of the pageblock itself so I'm not
sure why we don't unconditionally align up to pageblock_nr_pages here.  Is
there a legitimiate configuration where a pageblock will span multiple
pages of HPAGE_PMD_ORDER?

I think Joonsoo mentioned in some previous iteration that some arches may have this. But I have no idea.
But perhaps we could use HPAGE_PMD_ORDER instead of compound_order()?

In the locked case we know that PageLRU could not change so it still has to be a huge page so we know it's possible order.

In the !locked case, I'm now not even sure if the current code is safe enough. What if we pass the PageLRU check, but before the PageTransHuge check a compound page (THP or otherwise) materializes and we are at one of the tail pages. Then in DEBUG_VM configuration, this could fire in PageTransHuge() check: VM_BUG_ON_PAGE(PageTail(page), page);

--
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/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]