Re: [PATCH v4] mm/mempolicy,hugetlb: Checking hstate for hugetlbfs page in vma_migratable

["Li Xinhai" <lixinhai.lxh@gmail.com>]

On 2020-01-20 at 17:51 Anshuman Khandual wrote:
>
>
>On 01/16/2020 08:48 PM, Michal Hocko wrote:
>> On Thu 16-01-20 21:50:34, Li Xinhai wrote:
>>> On 2020-01-16 at 17:56 Michal Hocko wrote:
>>>> On Thu 16-01-20 04:11:25, Li Xinhai wrote:
>>>>> Checking hstate at early phase when isolating page, instead of during
>>>>> unmap and move phase, to avoid useless isolation.
>>>>
>>>> Could you be more specific what you mean by isolation and why does it
>>>> matter? The patch description should really explain _why_ the change is
>>>> needed or desirable.
>>>
>>> The changelog can be improved:
>>>
>>> vma_migratable() is called to check if pages in vma can be migrated
>>> before go ahead to isolate, unmap and move pages. For hugetlb pages,
>>> hugepage_migration_supported(struct hstate *h) is one factor which
>>> decide if migration is supported. In current code, this function is called
>>> from unmap_and_move_huge_page(), after isolating page has
>>> completed.
>>> This patch checks hstate from vma_migratable() and avoids isolating pages
>>> which are not supported.
>>
>> This still explains what but not why this is relevant. If by isolating
>> pages you mean isolate_lru_page then this really a noop for hugetlb
>> pages. Or do I still misread your changelog?
>
>unmap_and_move_hugepage() aborts migrating a HugeTLB page (from the list)
>if it's corresponding hstate does not support migration. IIUC the current
>proposal will enable early bail out and prevent migration via migrate_pages()
>at a much higher level like mbind() and other system calls if corresponding
>VMA is HugeTLB but it's hstate lacks migration support. This should probably
>save some cycles for HugeTLB VMAs. 

Thanks for comments. Yes，this patch is for enable early bail out.