Re: OOM behavior in constrained memory situations

[Paul Jackson <pj@sgi.com>]

Christoph wrote:
> There are situations in which memory allocations are restricted by policy, 
> by a cpuset or by type of allocation. 
> 
> I propose that we need different OOM behavior for the cases in which the
> user has imposed a limit on what type of memory to be allocated. In that 
> case the application should be terminate with OOM. The OOM killer should 
> not run.

I'll duck the discussion that followed your post as to whether some
sort of error or null return would be better than killing something.

If it is the case that some code path leads to the OOM killer, then
I don't agree that memory restrictions such as cpuset constraints
should mean we avoid the OOM killer.

I've already changed the OOM killer to only go after tasks in or
overlapping with the same cpuset.

static struct task_struct *select_bad_process(unsigned long *ppoints)
{
	...
	do_each_thread(g, p) {
		...
		/* If p's nodes don't overlap ours, it won't help to kill p. */
		if (!cpuset_excl_nodes_overlap(p))
			continue;
                                                    
I am guessing (you don't say) that your concern is that it seems
unfair for some app in some small cpuset to be able to trigger the
system-wide OOM killer.  The basic problem that this caused, that
of killing unrelated processes in entirely non-overlapping cpusets,
which was of no use in reducing the memory stress in the faulting
cpuset, is no longer a problem.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 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/