From: Xishi Qiu <qiuxishi@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
David Rientjes <rientjes@google.com>,
Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] mem-hotplug: alloc new page from the next node if zone is MOVABLE_ZONE
Date: Mon, 25 Jul 2016 09:52:21 +0800 [thread overview]
Message-ID: <579570D5.7060803@huawei.com> (raw)
In-Reply-To: <20160722131103.23c02a66d086df8f2ddae601@linux-foundation.org>
On 2016/7/23 4:11, Andrew Morton wrote:
> On Fri, 22 Jul 2016 10:57:48 +0800 Xishi Qiu <qiuxishi@huawei.com> wrote:
>
>> Memory offline could happen on both movable zone and non-movable zone.
>> We can offline the whole node if the zone is movable zone, and if the
>> zone is non-movable zone, we cannot offline the whole node, because
>> some kernel memory can't be migrated.
>>
>> So if we offline a node with movable zone, use prefer mempolicy to alloc
>> new page from the next node instead of the current node or other remote
>> nodes, because re-migrate is a waste of time and the distance of the
>> remote nodes is often very large.
>>
>> Also use GFP_HIGHUSER_MOVABLE to alloc new page if the zone is movable
>> zone.
>
> This conflicts pretty significantly with your "mem-hotplug: use
> different mempolicy in alloc_migrate_target()". Does it replace
> "mem-hotplug: use different mempolicy in alloc_migrate_target()" and
> your "mem-hotplug: use GFP_HIGHUSER_MOVABLE in,
> alloc_migrate_target()", or what?
>
Hi Andrew,
Yes, this patch is v2, "mem-hotplug: use different mempolicy in alloc_migrate_target()"
and "mem-hotplug: use GFP_HIGHUSER_MOVABLE in alloc_migrate_target()" are v1,
so just replace them.
Joonsoo and Vlastimil point that migratable pages are not always from user space,
so it is not correct to use GFP_HIGHUSER_MOVABLE in alloc_migrate_target().
David points that CMA and memory offline are distinct usecases and probably
deserve their own callbacks.
Thanks,
Xishi Qiu
>
> .
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
David Rientjes <rientjes@google.com>,
Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] mem-hotplug: alloc new page from the next node if zone is MOVABLE_ZONE
Date: Mon, 25 Jul 2016 09:52:21 +0800 [thread overview]
Message-ID: <579570D5.7060803@huawei.com> (raw)
In-Reply-To: <20160722131103.23c02a66d086df8f2ddae601@linux-foundation.org>
On 2016/7/23 4:11, Andrew Morton wrote:
> On Fri, 22 Jul 2016 10:57:48 +0800 Xishi Qiu <qiuxishi@huawei.com> wrote:
>
>> Memory offline could happen on both movable zone and non-movable zone.
>> We can offline the whole node if the zone is movable zone, and if the
>> zone is non-movable zone, we cannot offline the whole node, because
>> some kernel memory can't be migrated.
>>
>> So if we offline a node with movable zone, use prefer mempolicy to alloc
>> new page from the next node instead of the current node or other remote
>> nodes, because re-migrate is a waste of time and the distance of the
>> remote nodes is often very large.
>>
>> Also use GFP_HIGHUSER_MOVABLE to alloc new page if the zone is movable
>> zone.
>
> This conflicts pretty significantly with your "mem-hotplug: use
> different mempolicy in alloc_migrate_target()". Does it replace
> "mem-hotplug: use different mempolicy in alloc_migrate_target()" and
> your "mem-hotplug: use GFP_HIGHUSER_MOVABLE in,
> alloc_migrate_target()", or what?
>
Hi Andrew,
Yes, this patch is v2, "mem-hotplug: use different mempolicy in alloc_migrate_target()"
and "mem-hotplug: use GFP_HIGHUSER_MOVABLE in alloc_migrate_target()" are v1,
so just replace them.
Joonsoo and Vlastimil point that migratable pages are not always from user space,
so it is not correct to use GFP_HIGHUSER_MOVABLE in alloc_migrate_target().
David points that CMA and memory offline are distinct usecases and probably
deserve their own callbacks.
Thanks,
Xishi Qiu
>
> .
>
next prev parent reply other threads:[~2016-07-25 1:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-22 2:57 [PATCH v2] mem-hotplug: alloc new page from the next node if zone is MOVABLE_ZONE Xishi Qiu
2016-07-22 2:57 ` Xishi Qiu
2016-07-22 20:11 ` Andrew Morton
2016-07-22 20:11 ` Andrew Morton
2016-07-25 1:52 ` Xishi Qiu [this message]
2016-07-25 1:52 ` Xishi Qiu
2016-07-25 6:59 ` Vlastimil Babka
2016-07-25 6:59 ` Vlastimil Babka
2016-07-25 7:42 ` Xishi Qiu
2016-07-25 7:42 ` Xishi Qiu
2016-07-25 7:52 ` Vlastimil Babka
2016-07-25 7:52 ` Vlastimil Babka
2016-07-25 8:54 ` Xishi Qiu
2016-07-25 8:54 ` Xishi Qiu
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=579570D5.7060803@huawei.com \
--to=qiuxishi@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.