* Paul Jackson <[email protected]> wrote:
> Linus wrote:
> > Maybe you'd be willing on compromising by using a few kernel boot-time
> > command line options for your not-very-common load.
>
> If we were only a few options away from running Andy's varying load
> mix with something close to ideal performance, we'd be in fat city,
> and Andy would never have been driven to write that rant.
>
> There's more to it than that, but it is not as impossible as a battery
> with the efficiencies you (and the rest of us) dream of.
just to make sure i didnt get it wrong, wouldnt we get most of the
benefits Andy is seeking by having a: boot-time option which sets aside
a "hugetlb zone", with an additional sysctl to grow (or shrink) the pool
- with the growing happening on a best-effort basis, without guarantees?
i have implemented precisely such a scheme for 'bigpages' years ago, and
it worked reasonably well. (i was lazy and didnt implement it as a
resizable zone, but as a list of large pages taken straight off the
buddy allocator. This made dynamic resizing really easy and i didnt have
to muck with the buddy and mem_map[] data structures that zone-resizing
forces us to do. It had the disadvantage of those pages skewing the
memory balance of the affected zone.)
my quick solution was good enough that on a test-system i could resize
the pool across Oracle test-runs, when the box was otherwise quiet. I'd
expect a well-controlled HPC system to be equally resizable.
what we cannot offer is a guarantee to be able to grow the pool. Hence
the /proc mechanism would be called:
/proc/sys/vm/try_to_grow_hugemem_pool
to clearly stress the 'might easily fail' restriction. But if userspace
is well-behaved on Andy's systems (which it seems to be), then in
practice it should be resizable. On a generic system, only the boot-time
option is guaranteed to allocate as much RAM as possible. And once this
functionality has been clearly communicated and separated, the 'try to
alloc a large page' thing could become more agressive: it could attempt
to construct large pages if it can.
i dont think we object to such a capability, as long as the restrictions
are clearly communicated. (and no, that doesnt mean some obscure
Documentation/ entry - the restrictions have to be obvious from the
primary way of usage. I.e. no /proc/sys/vm/hugemem_pool_size thing where
growing could fail.)
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]
