Re: [PATCH] 0/2 Buddy allocator with placement policy (Version 9) + prezeroing (Version 4)

[Paul Jackson <pj@engr.sgi.com>]

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>