Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: "Li Xinhai" <lixinhai.lxh@gmail.com>
To: mhocko <mhocko@suse.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: Fri, 17 Jan 2020 11:16:32 +0800
Message-ID: <20200117111629898234212@gmail.com> (raw)
In-Reply-To: <20200116233817972969139@gmail.com>

On 2020-01-16 at 23:38 Li Xinhai wrote:
>On 2020-01-16 at 23:18 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?
>
>I mean isolate_huge_page will queue pages for moving, and
>unmap_and_move_huge_page will call
>hugepage_migration_supported then refuse moving.
> 

Forgot to mention that this patch has no relevant with this one
https://patchwork.kernel.org/patch/11331639/, 

Code change at here is common for avoids walking page table and
isolate hugepage in case architecture or page size are not supported
for migration. Comments from code are copied here:

static int unmap_and_move_huge_page(...)
{
	/*
	 * Migratability of hugepages depends on architectures and their size.
	 * This check is necessary because some callers of hugepage migration
	 * like soft offline and memory hotremove don't walk through page
	 * tables or check whether the hugepage is pmd-based or not before
	 * kicking migration.
	 */
	if (!hugepage_migration_supported(page_hstate(hpage))) {
		putback_active_hugepage(hpage);
		return -ENOSYS;
	}
}

For current code change, we are able to know the 'hstate' because we have 'vma', so
do early check instead of later.

>>--
>>Michal Hocko
>>SUSE Labs

  reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  4:11 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 [this message]
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
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 publically 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=20200117111629898234212@gmail.com \
    --to=lixinhai.lxh@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --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

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org
	public-inbox-index linux-mm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git