[lkml]   [2006]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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))

    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 <> 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: 2006-02-07 00:02    [W:0.020 / U:210.536 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site