From: Mike Kravetz <mike.kravetz@oracle.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Li Xinhai <lixinhai.lxh@gmail.com>,
linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Michal Hocko <mhocko@suse.com>,
linux-man <linux-man@vger.kernel.org>
Subject: Re: [PATCH] mm/mempolicy: support MPOL_MF_STRICT for huge page mapping
Date: Mon, 10 Feb 2020 09:19:48 -0800 [thread overview]
Message-ID: <07cd0750-d908-dd3b-dee1-bc3fcf5bf771@oracle.com> (raw)
In-Reply-To: <1580434395-9962-1-git-send-email-lixinhai.lxh@gmail.com>
On 1/30/20 5:33 PM, Li Xinhai wrote:
> MPOL_MF_STRICT is used in mbind() for purposes:
> (1) MPOL_MF_STRICT is set alone without MPOL_MF_MOVE or MPOL_MF_MOVE_ALL,
> to check if there is misplaced page and return -EIO;
> (2) MPOL_MF_STRICT is set with MPOL_MF_MOVE or MPOL_MF_MOVE_ALL, to check
> if there is misplaced page which is failed to isolate, or page is
> success on isolate but failed to move, and return -EIO.
>
> For non hugepage mapping, (1) and (2) are implemented as expectation.
> For hugepage mapping, (1) is not implemented. And in (2), the part about
> failed to isolate and report -EIO is not implemented.
>
> This patch implements the missed parts for hugepage mapping. Benefits
> with it applied:
> - User space can apply same code logic to handle mbind() on hugepage and
> non hugepage mapping;
> - Reliably using MPOL_MF_STRICT alone to check whether there is misplaced
> page or not when bind policy on address range, especially for address
> range which contains both hugepage and non hugepage mapping.
>
> Analysis of potential impact on existing users:
> - For users who using MPOL_MF_STRICT alone, since mbind() don't report
> reliable answer about misplaced page, their existing code have to
> utilize other facilities, e.g. numa_maps of proc, to check misplaced
> page. After this patch applied, that dedicated checking will still work
> without been impacted;
> - For users who using MPOL_MF_STRICT with MPOL_MF_MOVE or
> MPOL_MF_MOVE_ALL, the semantic about some pages could not be moved will
> not be changed by this patch, because failed to isolate and failed to
> move have same effects to users, so their existing code will not be
> impacted.
>
> In mbind man page, the note about 'MPOL_MF_STRICT is ignored on huge page
> mappings' can be removed after this patch is applied.
>
> Signed-off-by: Li Xinhai <lixinhai.lxh@gmail.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Cc: linux-man <linux-man@vger.kernel.org>
Hello Naoya,
Do you have any thoughts on this? In previous discussions you suggested this
approach of removing the special casing for hugetlb pages. The code looks
good to me and patch is fine with commmit message modification. Just wanted
to get your opinion.
--
Mike Kravetz
next prev parent reply other threads:[~2020-02-10 17:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-31 1:33 [PATCH] mm/mempolicy: support MPOL_MF_STRICT for huge page mapping Li Xinhai
2020-02-01 3:28 ` Mike Kravetz
2020-02-01 13:56 ` Li Xinhai
2020-02-10 17:19 ` Mike Kravetz [this message]
2020-02-12 3:21 ` HORIGUCHI NAOYA(堀口 直也)
2020-02-12 5:25 ` Li Xinhai
2020-02-12 23:50 ` Mike Kravetz
2020-02-13 1:50 ` Li Xinhai
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=07cd0750-d908-dd3b-dee1-bc3fcf5bf771@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lixinhai.lxh@gmail.com \
--cc=mhocko@suse.com \
--cc=n-horiguchi@ah.jp.nec.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).