[lkml]   [2018]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration
On Wed 03-10-18 17:07:13, Anshuman Khandual wrote:
> On 10/03/2018 04:29 PM, Michal Hocko wrote:
> > It is not the platform that decides. That is the whole point of the
> > distinction. It is us to say what is feasible and what we want to
> > support. Do we want to support giga pages in zone_movable? Under which
> > conditions? See my point?
> So huge_movable() is going to be a generic MM function deciding on the
> feasibility for allocating a huge page of 'size' from movable zone during
> migration.

Yeah, this might be a more complex logic than just the size check. If
there is a sufficient pre-allocated pool to migrate the page off it
might be pre-reserved for future migration etc... Nothing to be done
right now of course.

> If the feasibility turns out to be negative, then migration
> process is aborted there.

You are still confusing allocation and migration here I am afraid. The
whole "feasible to migrate" is for the _allocation_ time when we decide
whether the new page should be placed in zone_movable or not.

> huge_movable() will do something like these:
> - Return positive right away on smaller size huge pages
> - Measure movable allocation feasibility for bigger huge pages
> - Look out for free_pages in the huge page order in movable areas
> - if (order > (MAX_ORDER - 1))
> - Scan the PFN ranges in movable zone for possible allocation
> - etc
> - etc
> Did I get this right ?

Well, not really. I was thinking of something like this for the
if (!arch_hugepage_migration_supporte())
return false;
if (hstate_is_gigantic(h))
return false;
return true;

further changes might be done on top of this.
Michal Hocko

 \ /
  Last update: 2018-10-03 13:49    [W:0.312 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site