From: Michal Hocko <mhocko@suse.cz>
To: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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
Subject: Re: [PATCH v2 0/6] mm/hugetlb: gigantic hugetlb page pools shrink supporting
Date: Tue, 16 Apr 2013 18:11:44 -0700 [thread overview]
Message-ID: <20130417011144.GA20835@dhcp22.suse.cz> (raw)
In-Reply-To: <1366158995-3116-1-git-send-email-liwanp@linux.vnet.ibm.com>
On Wed 17-04-13 08:36:28, Wanpeng Li wrote:
> Changelog:
> * add comments from Andi which indicate shrink gigantic hugetlb page pools make
> sense to patchset description.
>
> 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.
>
> http://marc.info/?l=linux-mm&m=136578016214512&w=2
> Andi thinks this idea make sense since he is working on a new patchkit to
> allocate GB pages from CMA. With that freeing actually makes sense, as the
> pages can be reallocated.
But that is not implemented yet...
>
> Testcase:
> boot: hugepagesz=1G hugepages=10
>
> [root@localhost hugepages]# free -m
> total used free shared buffers cached
> Mem: 36269 10836 25432 0 11 288
> -/+ buffers/cache: 10537 25732
> Swap: 35999 0 35999
> [root@localhost hugepages]# echo 0 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
> -bash: echo: write error: Invalid argument
> [root@localhost hugepages]# echo 1 > /proc/sys/vm/hugetlb_shrink_gigantic_pool
I have asked that already but it didn't get answered. What is the reason
for an explicit knob to enable this? It just adds an additional code and
it doesn't make much sense to me to be honest.
[...]
--
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>
next prev parent reply other threads:[~2013-04-17 1:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-17 0:36 [PATCH v2 0/6] mm/hugetlb: gigantic hugetlb page pools shrink supporting Wanpeng Li
2013-04-17 0:36 ` [PATCH v2 1/6] mm/hugetlb: introduce new sysctl knob which control gigantic page pools shrinking Wanpeng Li
2013-04-17 0:36 ` [PATCH v2 2/6] mm/hugetlb: update_and_free_page gigantic pages awareness Wanpeng Li
2013-04-17 0:36 ` [PATCH v2 3/6] mm/hugetlb: enable gigantic hugetlb page pools shrinking Wanpeng Li
2013-04-17 0:36 ` [PATCH v2 4/6] mm/hugetlb: use already exist huge_page_order() instead of h->order Wanpeng Li
2013-04-17 0:36 ` [PATCH v2 5/6] mm/hugetlb: remove redundant hugetlb_prefault Wanpeng Li
2013-04-17 0:36 ` [PATCH v2 6/6] mm/hugetlb: use already exist interface huge_page_shift Wanpeng Li
2013-04-17 1:11 ` Michal Hocko [this message]
2013-04-17 1:19 ` [PATCH v2 0/6] mm/hugetlb: gigantic hugetlb page pools shrink supporting Wanpeng Li
2013-04-17 1:19 ` 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=20130417011144.GA20835@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=dhillf@gmail.com \
--cc=kamezawa.hiroyu@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=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 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).