lkml.org 
[lkml]   [2005]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] 0/2 Buddy allocator with placement policy (Version 9) + prezeroing (Version 4)
    Mel Gorman, responding to Dave Hansen 
    > > The other thing is that we'll probably have to be a lot more strict
    > > about how the allocations fall back. Some users will probably prefer to
    > > kill an application rather than let a kernel allocation fall back into a
    > > user memory area.
    > >
    >
    > That will be a tad trickier because we'll need a way of specifying a
    > "fallback policy" at configure time. However, the fallback policy is
    > currently isolated within one while loop, having different fallback
    > policies is doable. The kicker is that that there might be nasty
    > interaction with the page reclaim code where the allocator is not falling
    > back due to policy but the reclaim code things everything is just fine.

    There is at least one, perhaps a few, policies that I'd like to see in
    the current allocator as well.

    In particular, I am working on preparing a patch proposal for a policy
    that would kill a task rather than invoke the swapper. In
    mm/page_alloc.c __alloc_pages(), if one gets down to the point of being
    about to kick the swapper, if this policy is enabled (and you're not
    in_interrupt() and don't have flag PF_MEMALLOC set), then ask
    oom_kill_task() to shoot us instead. For some big HPC jobs that are
    carefully sized to fit on the allowed memory nodes, swapping is a fate
    worse than death.

    The natural place (for me, anyway) to hang such policies is off the
    cpuset.

    I am hopeful that cpusets will soon hit Linus's tree.

    Would it make sense to specify these buddy allocator fallback policies
    per cpuset as well?

    I'd be glad to investigate providing the cpuset part of the code,
    exposing the appropriate boolean, enum, scalar or bitmap type(s) to user
    land query and setting, as another file in each cpuset directory, if
    that would facilitate this.

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
    -
    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-03-22 14:11    [W:0.038 / U:29.408 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site