Messages in this thread | | | Date | Mon, 6 Feb 2006 14:59:22 -0800 | From | Paul Jackson <> | Subject | Re: OOM behavior in constrained memory situations |
| |
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/
| |