Re: [PATCH v2 10/12] mm: mempolicy: mbind and migrate_pages support thp migration

[Naoya Horiguchi]

On Fri, Nov 25, 2016 at 05:57:20PM +0530, Anshuman Khandual wrote:
> On 11/08/2016 05:01 AM, Naoya Horiguchi wrote:
...
> > @@ -497,30 +541,15 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned long addr,
> >  	struct page *page;
> >  	struct queue_pages *qp = walk->private;
> >  	unsigned long flags = qp->flags;
> > -	int nid, ret;
> > +	int ret;
> >  	pte_t *pte;
> >  	spinlock_t *ptl;
> >  
> > -	if (pmd_trans_huge(*pmd)) {
> > -		ptl = pmd_lock(walk->mm, pmd);
> > -		if (pmd_trans_huge(*pmd)) {
> > -			page = pmd_page(*pmd);
> > -			if (is_huge_zero_page(page)) {
> > -				spin_unlock(ptl);
> > -				__split_huge_pmd(vma, pmd, addr, false, NULL);
> > -			} else {
> > -				get_page(page);
> > -				spin_unlock(ptl);
> > -				lock_page(page);
> > -				ret = split_huge_page(page);
> > -				unlock_page(page);
> > -				put_page(page);
> > -				if (ret)
> > -					return 0;
> > -			}
> > -		} else {
> > -			spin_unlock(ptl);
> > -		}
> > +	ptl = pmd_trans_huge_lock(pmd, vma);
> > +	if (ptl) {
> > +		ret = queue_pages_pmd(pmd, ptl, addr, end, walk);
> > +		if (ret)
> > +			return 0;
> >  	}
> 
> I wonder if we should introduce pte_entry function along with pmd_entry
> function as we are first looking for trans huge PMDs either for direct
> addition into the migration list or splitting it before looking for PTEs.

Most of pagewalk users don't define pte_entry because of performance reason
(to avoid the overhead of PTRS_PER_PMD function calls).
But that could be a nice cleanup if we have a workaround.

Thanks,
Naoya Horiguchi