Naoya Horiguchi [off-list ref] writes:

On Wed, Jul 31, 2013 at 12:02:30AM +0530, Aneesh Kumar K.V wrote:

quoted

Naoya Horiguchi [off-list ref] writes:

quoted

Now hugepages are definitely movable. So allocating hugepages from
ZONE_MOVABLE is natural and we have no reason to keep this parameter.
In order to allow userspace to prepare for the removal, let's leave
this sysctl handler as noop for a while.

I guess you still need to handle architectures for which pmd_huge is

int pmd_huge(pmd_t pmd)
{
	return 0;
}

embedded powerpc is one. They don't store pte information at the PMD
level. Instead pmd contains a pointer to hugepage directory which
contain huge pte.

It seems that this comment is for the whole series, not just for this
patch, right?

Some users of hugepage migration (mbind, move_pages, migrate_pages)
walk over page tables to collect hugepages to be migrated, where
hugepages are just ignored in such architectures due to pmd_huge.
So no problem for these users.

But the other users (softoffline, memory hotremove) choose hugepages
to be migrated based on pfn, where they don't check pmd_huge.
As you wrote, this can be problematic for such architectures.
So I think of adding pmd_huge() check somewhere (in unmap_and_move_huge_page
for example) to make it fail for such architectures.

Considering that we have architectures that won't support migrating
explicit hugepages with this patch series, is it ok to use
GFP_HIGHUSER_MOVABLE for hugepage allocation ?

-aneesh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>