* Linus Torvalds <[email protected]> wrote:
> Boot-time option to set the hugetlb zone, yes.
>
> Grow-or-shrink, probably not. Not in practice after bootup on any
> machine that is less than idle.
>
> The zones have to be pretty big to make any sense. You don't just grow
> them or shrink them - they'd be on the order of tens of megabytes to
> gigabytes. In other words, sized big enough that you will _not_ be
> able to create them on demand, except perhaps right after boot.
i think the current hugepages=<N> boot option could transparently be
morphed into a 'separate zone' approach, and /proc/sys/vm/nr_hugepages
would just refuse to change (or would go away altogether). Dynamically
growing zones seem like a lot of trouble, without much gain. [ OTOH
hugepages= parameter unit should be changed from the current 'number of
hugepages' to plain RAM metrics - megabytes/gigabytes. ]
that would solve two problems: any 'zone VM statistics skewing effect'
of the current hugetlbs (which is a preallocated list of really large
pages) would go away, and the hugetlb zone could potentially be utilized
for easily freeable objects.
this would already be alot more flexible that what we have: the hugetlb
area would not be 'lost' altogether, like now. Once we are at this stage
we can see how usable it is in practice. I strongly suspect it will
cover most of the HPC uses.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
