[lkml]   [2005]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

    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 <> 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:11    [W:0.020 / U:5.664 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site