linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Li Xinhai" <lixinhai.lxh@gmail.com>
To: mhocko <mhocko@suse.com>
Cc: "Mike Kravetz" <mike.kravetz@oracle.com>,
	 "linux-mm@kvack.org" <linux-mm@kvack.org>,
	 akpm <akpm@linux-foundation.org>,
	 yang.shi <yang.shi@linux.alibaba.com>,
	 n-horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [PATCH 2/2] mm/mempolicy: Skip walking HUGETLB vma if MPOL_MF_STRICT is specified alone
Date: Tue, 21 Jan 2020 22:15:43 +0800	[thread overview]
Message-ID: <20200121221540529432413@gmail.com> (raw)
In-Reply-To: 20200120124511.GC18451@dhcp22.suse.cz

On 2020-01-20 at 20:45 Michal Hocko wrote:
>On Fri 17-01-20 23:46:03, Li Xinhai wrote:
>[...]
>> >> by call mbind then check the
>> >> numa_maps, instead of just call mbind. So, I'd like option #3 is there. That is
>> >> a simple change, and I am glad to add this function if no objection.
>> >
>> >Any reason you cannot use move_pages syscall?
>>
>> I use it, that is the 'take action later' mentioned above, I'd like to
>> know if there are misplace pages before call it if mbind can help
>> to give answer.
>
>I am sorry but I do not follow? Why do you need to do two steps? Why
>don't you simply call move_pages right away? 
I am trying to decrease the number of call to move_pages(). For
call move_pages(), we need prepare parameters in array for 'pages',
'nodes' (i.e., it do not support moving pages as specified through start addr
and length), which could be cost.

One way for handling my case is 
- mbind: set policy without detecting if any pages misplaced nor moving 
  pages.
(continue below part when timing is right)
- move_pages:  call on pages which are within range of above mbind.

The other way is:
- mbind: set policy and detects if any pages are misplaced.
(continue below part when timing is right)
- move_pages:  call on pages which are within range has misplaced pages.

Knowing about misplaced pages from mbind will give me flexibility for
choosing different solutions.

>
>--
>Michal Hocko
>SUSE Labs

  reply	other threads:[~2020-01-21 14:15 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14  9:16 [PATCH 1/2] mm/mempolicy: Checking hstate for hugetlbfs page in vma_migratable Li Xinhai
2020-01-14  9:16 ` [PATCH 2/2] mm/mempolicy: Skip walking HUGETLB vma if MPOL_MF_STRICT is specified alone Li Xinhai
2020-01-14 14:09   ` Li Xinhai
2020-01-14 18:27     ` Yang Shi
2020-01-15  1:07     ` Mike Kravetz
2020-01-15  1:24       ` Yang Shi
2020-01-15  4:28         ` Mike Kravetz
2020-01-15  5:23           ` Yang Shi
2020-01-15  7:36             ` Li Xinhai
2020-01-15 17:16               ` Yang Shi
2020-01-15 21:07       ` Mike Kravetz
2020-01-15 21:30         ` Yang Shi
2020-01-15 21:45           ` Mike Kravetz
2020-01-15 21:59             ` Yang Shi
2020-01-16  8:07               ` HORIGUCHI NAOYA(堀口 直也)
2020-01-16 15:32                 ` Li Xinhai
2020-01-16  7:59         ` Michal Hocko
2020-01-16 19:22           ` Mike Kravetz
2020-01-17  2:32             ` Yang Shi
2020-01-17  2:38             ` Li Xinhai
2020-01-17  7:57               ` Michal Hocko
2020-01-17 12:05                 ` Li Xinhai
2020-01-17 15:20                   ` Michal Hocko
2020-01-17 15:46                     ` Li Xinhai
2020-01-20 12:45                       ` Michal Hocko
2020-01-21 14:15                         ` Li Xinhai [this message]
2020-01-21 14:53                           ` Michal Hocko
2020-01-22 13:55                             ` Li Xinhai
2020-01-14 19:12 ` [PATCH 1/2] mm/mempolicy: Checking hstate for hugetlbfs page in vma_migratable Mike Kravetz
2020-01-15  1:25 ` Andrew Morton

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=20200121221540529432413@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 \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=yang.shi@linux.alibaba.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).