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
beginning
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
SUSE Labs
