From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Michal Hocko <mhocko@suse.com>, Li Xinhai <lixinhai.lxh@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
akpm <akpm@linux-foundation.org>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH v4] mm/mempolicy,hugetlb: Checking hstate for hugetlbfs page in vma_migratable
Date: Mon, 20 Jan 2020 14:51:31 +0530 [thread overview]
Message-ID: <b9024406-7e80-3e17-d79f-395c3669b53f@arm.com> (raw)
In-Reply-To: <20200116151803.GV19428@dhcp22.suse.cz>
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.
next prev parent reply other threads:[~2020-01-20 9:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 4:11 [PATCH v4] mm/mempolicy,hugetlb: Checking hstate for hugetlbfs page in vma_migratable Li Xinhai
2020-01-16 9:56 ` Michal Hocko
2020-01-16 13:50 ` Li Xinhai
2020-01-16 15:18 ` Michal Hocko
2020-01-16 15:38 ` Li Xinhai
2020-01-17 3:16 ` Li Xinhai
2020-01-18 3:11 ` Li Xinhai
2020-01-18 15:27 ` Li Xinhai
2020-01-20 10:12 ` Michal Hocko
2020-01-20 15:37 ` Li Xinhai
2020-01-20 16:05 ` Michal Hocko
2020-01-21 3:42 ` Anshuman Khandual
2020-01-21 13:08 ` Li Xinhai
2020-01-21 12:44 ` Li Xinhai
2020-01-20 9:21 ` Anshuman Khandual [this message]
2020-01-20 11:32 ` Michal Hocko
2020-01-21 3:22 ` Anshuman Khandual
2020-01-20 14:19 ` Li Xinhai
2020-01-22 6:05 ` Anshuman Khandual
2020-01-22 13:21 ` Li Xinhai
2020-01-23 7:48 ` Anshuman Khandual
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9024406-7e80-3e17-d79f-395c3669b53f@arm.com \
--to=anshuman.khandual@arm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=lixinhai.lxh@gmail.com \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).