From: Wanpeng Li <liwanp@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andi Kleen <ak@linux.intel.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
Hillf Danton <dhillf@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Wanpeng Li <liwanp@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/6] mm/hugetlb: gigantic hugetlb page pools shrink supporting
Date: Fri, 5 Apr 2013 09:29:21 +0800 [thread overview]
Message-ID: <20130405012921.GA3313@hacker.(null)> (raw)
In-Reply-To: <20130404162023.GQ29911@dhcp22.suse.cz>
On Thu, Apr 04, 2013 at 06:20:23PM +0200, Michal Hocko wrote:
>On Thu 04-04-13 18:17:46, Michal Hocko wrote:
>> On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
>> > order >= MAX_ORDER pages are only allocated at boot stage using the
>> > bootmem allocator with the "hugepages=xxx" option. These pages are never
>> > free after boot by default since it would be a one-way street(>= MAX_ORDER
>> > pages cannot be allocated later), but if administrator confirm not to
>> > use these gigantic pages any more, these pinned pages will waste memory
>> > since other users can't grab free pages from gigantic hugetlb pool even
>> > if OOM, it's not flexible. The patchset add hugetlb gigantic page pools
>> > shrink supporting. Administrator can enable knob exported in sysctl to
>> > permit to shrink gigantic hugetlb pool.
>>
>> I am not sure I see why the new knob is needed.
>> /sys/kernel/mm/hugepages/hugepages-*/nr_hugepages is root interface so
>> an additional step to allow writing to the file doesn't make much sense
>> to me to be honest.
>>
>> Support for shrinking gigantic huge pages makes some sense to me but I
>> would be interested in the real world example. GB pages are usually used
>> in very specific environments where the amount is usually well known.
>>
>> I could imagine nr_hugepages_mempolicy would make more sense to free
>> pages from particular nodes so they could be offlined for example.
>> Does the patchset handles this as well?
>
>Ohh, I should have checked before asking. Both knobs use the same
>hugetlb_sysctl_handler_common and unless there is something hardcoded in
>the patches then it should be supproted.
I'm very happy if you can review this patchset in details, any comments
are welcome. ;-)
Regards,
Wanpeng Li
>
>--
>Michal Hocko
>SUSE Labs
>
>--
>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>
--
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>
next prev parent reply other threads:[~2013-04-05 1:30 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-04 9:09 [PATCH 0/6] mm/hugetlb: gigantic hugetlb page pools shrink supporting Wanpeng Li
2013-04-04 9:09 ` Wanpeng Li
2013-04-04 9:09 ` [PATCH 1/6] mm/hugetlb: introduce new sysctl knob which control gigantic page pools shrinking Wanpeng Li
2013-04-04 9:09 ` Wanpeng Li
2013-04-04 9:09 ` [PATCH 2/6] mm/hugetlb: update_and_free_page gigantic pages awareness Wanpeng Li
2013-04-04 9:09 ` Wanpeng Li
2013-04-04 9:09 ` [PATCH 3/6] mm/hugetlb: enable gigantic hugetlb page pools shrinking Wanpeng Li
2013-04-04 9:09 ` Wanpeng Li
2013-04-04 9:09 ` [PATCH 4/6] mm/hugetlb: use already exist huge_page_order() instead of h->order Wanpeng Li
2013-04-04 9:09 ` Wanpeng Li
2013-04-04 9:09 ` [PATCH 5/6] mm/hugetlb: remove redundant hugetlb_prefault Wanpeng Li
2013-04-04 9:09 ` Wanpeng Li
2013-04-04 9:09 ` [PATCH 6/6] mm/hugetlb: use already exist interface huge_page_shift Wanpeng Li
2013-04-04 9:09 ` Wanpeng Li
2013-04-04 16:17 ` [PATCH 0/6] mm/hugetlb: gigantic hugetlb page pools shrink supporting Michal Hocko
2013-04-04 16:17 ` Michal Hocko
2013-04-04 16:20 ` Michal Hocko
2013-04-04 16:20 ` Michal Hocko
2013-04-05 1:29 ` Wanpeng Li [this message]
2013-04-05 1:29 ` Wanpeng Li
2013-04-04 23:41 ` Wanpeng Li
2013-04-04 23:41 ` Wanpeng Li
2013-04-05 8:12 ` Michal Hocko
2013-04-05 8:12 ` Michal Hocko
2013-04-05 8:27 ` Wanpeng Li
2013-04-05 9:27 ` Michal Hocko
2013-04-05 9:27 ` Michal Hocko
2013-04-05 8:27 ` Wanpeng Li
2013-04-05 8:54 ` Simon Jeons
2013-04-05 8:54 ` Simon Jeons
2013-04-05 9:52 ` Michal Hocko
2013-04-05 9:52 ` Michal Hocko
2013-04-04 23:35 ` Wanpeng Li
2013-04-04 23:35 ` Wanpeng Li
2013-04-11 23:29 ` Wanpeng Li
2013-04-12 15:22 ` Andi Kleen
2013-04-12 15:22 ` Andi Kleen
2013-07-15 11:31 ` Wanpeng Li
2013-07-15 11:31 ` Wanpeng Li
2014-08-21 23:37 ` Wanpeng Li
2014-08-21 23:37 ` Wanpeng Li
2014-08-22 1:34 ` Zhang Yanfei
2014-08-22 1:34 ` Zhang Yanfei
2014-08-22 4:04 ` Wanpeng Li
2014-08-22 4:04 ` Wanpeng Li
2014-08-22 14:18 ` Andi Kleen
2014-08-22 14:18 ` Andi Kleen
2013-04-11 23:29 ` 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='20130405012921.GA3313@hacker.(null)' \
--to=liwanp@linux.vnet.ibm.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dhillf@gmail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--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.