From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
Hugh Dickins <hughd@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andi Kleen <andi@firstfloor.org>, Hillf Danton <dhillf@gmail.com>,
Michal Hocko <mhocko@suse.cz>, Rik van Riel <riel@redhat.com>,
Wanpeng Li <liwanp@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable
Date: Tue, 06 Aug 2013 07:22:02 +0530 [thread overview]
Message-ID: <87haf3oabh.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1375411396-bw4cbhso-mutt-n-horiguchi@ah.jp.nec.com>
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> writes:
>>
>> Considering that we have architectures that won't support migrating
>> explicit hugepages with this patch series, is it ok to use
>> GFP_HIGHUSER_MOVABLE for hugepage allocation ?
>
> Originally this parameter was introduced to make hugepage pool on ZONE_MOVABLE.
> The benefit is that we can extend the hugepage pool more easily,
> because external fragmentation less likely happens than other zone type
> by rearranging fragmented pages with page migration/reclaim.
>
> So I think using ZONE_MOVABLE for hugepage allocation by default makes sense
> even on the architectures which don't support hugepage migration.
But allocating hugepages from ZONE_MOVABLE means we have pages in that
zone which we can't migrate. Doesn't that impact other features like
hotplug ?
-aneesh
--
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: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
Hugh Dickins <hughd@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andi Kleen <andi@firstfloor.org>, Hillf Danton <dhillf@gmail.com>,
Michal Hocko <mhocko@suse.cz>, Rik van Riel <riel@redhat.com>,
Wanpeng Li <liwanp@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable
Date: Tue, 06 Aug 2013 07:22:02 +0530 [thread overview]
Message-ID: <87haf3oabh.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1375411396-bw4cbhso-mutt-n-horiguchi@ah.jp.nec.com>
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> writes:
>>
>> Considering that we have architectures that won't support migrating
>> explicit hugepages with this patch series, is it ok to use
>> GFP_HIGHUSER_MOVABLE for hugepage allocation ?
>
> Originally this parameter was introduced to make hugepage pool on ZONE_MOVABLE.
> The benefit is that we can extend the hugepage pool more easily,
> because external fragmentation less likely happens than other zone type
> by rearranging fragmented pages with page migration/reclaim.
>
> So I think using ZONE_MOVABLE for hugepage allocation by default makes sense
> even on the architectures which don't support hugepage migration.
But allocating hugepages from ZONE_MOVABLE means we have pages in that
zone which we can't migrate. Doesn't that impact other features like
hotplug ?
-aneesh
next prev parent reply other threads:[~2013-08-06 1:52 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 4:54 [PATCH v4 0/8] extend hugepage migration Naoya Horiguchi
2013-07-25 4:54 ` Naoya Horiguchi
2013-07-25 4:54 ` [PATCH 1/8] migrate: make core migration code aware of hugepage Naoya Horiguchi
2013-07-25 4:54 ` Naoya Horiguchi
2013-07-25 6:06 ` Hillf Danton
2013-07-25 6:06 ` Hillf Danton
2013-07-30 18:28 ` Aneesh Kumar K.V
2013-07-30 18:28 ` Aneesh Kumar K.V
2013-07-30 18:48 ` Naoya Horiguchi
2013-07-30 18:48 ` Naoya Horiguchi
2013-07-25 4:54 ` [PATCH 2/8] soft-offline: use migrate_pages() instead of migrate_huge_page() Naoya Horiguchi
2013-07-25 4:54 ` Naoya Horiguchi
2013-07-25 6:09 ` Hillf Danton
2013-07-25 6:09 ` Hillf Danton
2013-07-25 4:54 ` [PATCH 3/8] migrate: add hugepage migration code to migrate_pages() Naoya Horiguchi
2013-07-25 4:54 ` Naoya Horiguchi
2013-07-25 6:17 ` Hillf Danton
2013-07-25 6:17 ` Hillf Danton
2013-07-25 4:54 ` [PATCH 4/8] migrate: add hugepage migration code to move_pages() Naoya Horiguchi
2013-07-25 4:54 ` Naoya Horiguchi
2013-07-25 4:55 ` [PATCH 5/8] mbind: add hugepage migration code to mbind() Naoya Horiguchi
2013-07-25 4:55 ` Naoya Horiguchi
2013-07-25 6:33 ` Hillf Danton
2013-07-25 6:33 ` Hillf Danton
2013-07-25 4:55 ` [PATCH 6/8] migrate: remove VM_HUGETLB from vma flag check in vma_migratable() Naoya Horiguchi
2013-07-25 4:55 ` Naoya Horiguchi
2013-07-25 4:55 ` [PATCH 7/8] memory-hotplug: enable memory hotplug to handle hugepage Naoya Horiguchi
2013-07-25 4:55 ` Naoya Horiguchi
2013-07-25 4:55 ` [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable Naoya Horiguchi
2013-07-25 4:55 ` Naoya Horiguchi
2013-07-30 18:32 ` Aneesh Kumar K.V
2013-07-30 18:32 ` Aneesh Kumar K.V
2013-07-31 20:24 ` Naoya Horiguchi
2013-07-31 20:24 ` Naoya Horiguchi
2013-08-01 5:59 ` Aneesh Kumar K.V
2013-08-01 5:59 ` Aneesh Kumar K.V
2013-08-02 2:43 ` Naoya Horiguchi
2013-08-02 2:43 ` Naoya Horiguchi
2013-08-06 1:52 ` Aneesh Kumar K.V [this message]
2013-08-06 1:52 ` Aneesh Kumar K.V
2013-08-06 4:30 ` Naoya Horiguchi
2013-08-06 4:30 ` Naoya Horiguchi
2013-08-05 20:27 ` [PATCH 9/8] hugetlb: add pmd_huge_support() to migrate only pmd-based hugepage Naoya Horiguchi
2013-08-05 20:27 ` Naoya Horiguchi
2013-08-06 1:56 ` Aneesh Kumar K.V
2013-08-06 1:56 ` Aneesh Kumar K.V
2013-08-06 4:48 ` Naoya Horiguchi
2013-08-06 4:48 ` Naoya Horiguchi
-- strict thread matches above, loose matches on Subject: below --
2013-07-18 21:34 [PATCH v3 0/8] extend hugepage migration Naoya Horiguchi
2013-07-18 21:34 ` [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-24 3:46 ` Wanpeng Li
2013-07-24 3:46 ` Wanpeng Li
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=87haf3oabh.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=dhillf@gmail.com \
--cc=hughd@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liwanp@linux.vnet.ibm.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=nao.horiguchi@gmail.com \
--cc=riel@redhat.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 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.