lkml.org 
[lkml]   [2005]   [Nov]   [4]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateFri, 4 Nov 2005 07:38:20 +0100
    FromIngo Molnar <>
    SubjectRe: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
    * Paul Jackson <pj@sgi.com> 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 majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2005-11-04 07:41    [from the cache]
    ©2003-2008