On Fri 05-04-13 07:41:23, Wanpeng Li wrote:On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:Yes, I am aware of that but the question remains the same (andOn Thu 04-04-13 17:09:08, Wanpeng Li wrote:Gigantic huge pages in hugetlb means h->order >= MAX_ORDER instead of GBorder >= MAX_ORDER pages are only allocated at boot stage using theI am not sure I see why the new knob is needed.
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.
/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.
pages. ;-)
unanswered). What is the use case?