On 1/6/21 8:35 AM, Michal Hocko wrote:

On Wed 06-01-21 16:47:35, Muchun Song wrote:

quoted

Because we only can isolate a active page via isolate_huge_page()
and hugetlbfs_fallocate() forget to mark it as active, we cannot
isolate and migrate those pages.

I've little bit hard time to understand this initially and had to dive
into the code to make sense of it. I would consider the following
wording easier to grasp. Feel free to reuse if you like.
"
If a new hugetlb page is allocated during fallocate it will not be
marked as active (set_page_huge_active) which will result in a later
isolate_huge_page failure when the page migration code would like to
move that page. Such a failure would be unexpected and wrong.
"

Now to the fix. I believe that this patch shows that the
set_page_huge_active is just too subtle. Is there any reason why we
cannot make all freshly allocated huge pages active by default?

I looked into that yesterday.  The primary issue is in page fault code,
hugetlb_no_page is an example.  If page_huge_active is set, then it can
be isolated for migration.  So, migration could race with the page fault
and the page could be migrated before being added to the page table of
the faulting task.  This was an issue when hugetlb_no_page set_page_huge_active
right after allocating and clearing the huge page.  Commit cb6acd01e2e4
moved the set_page_huge_active after adding the page to the page table
to address this issue.
-- 
Mike Kravetz