> Tasks that do not share the same set of allowed nodes with the task that
> triggered the oom should not be considered as candidates for oom kill.
>
> Tasks in other cpusets with a disjoint set of mems would be unfairly
> penalized otherwise because of oom conditions elsewhere; an extreme
> example could unfairly kill all other applications on the system if a
> single task in a user's cpuset sets itself to OOM_DISABLE and then uses
> more memory than allowed.
>
> Killing tasks outside of current's cpuset rarely would free memory for
> current anyway. To use a sane heuristic, we must ensure that killing a
> task would likely free memory for current and avoid needlessly killing
> others at all costs just because their potential memory freeing is
> unknown. It is better to kill current than another task needlessly.
I've put following historically remark in the description of the patch.
We applied the exactly same patch in 2005:
: commit ef08e3b4981aebf2ba9bd7025ef7210e8eec07ce
: Author: Paul Jackson <pj@xxxxxxx>
: Date: Tue Sep 6 15:18:13 2005 -0700
:
: [PATCH] cpusets: confine oom_killer to mem_exclusive cpuset
:
: Now the real motivation for this cpuset mem_exclusive patch series seems
: trivial.
:
: This patch keeps a task in or under one mem_exclusive cpuset from provoking an
: oom kill of a task under a non-overlapping mem_exclusive cpuset. Since only
: interrupt and GFP_ATOMIC allocations are allowed to escape mem_exclusive
: containment, there is little to gain from oom killing a task under a
: non-overlapping mem_exclusive cpuset, as almost all kernel and user memory
: allocation must come from disjoint memory nodes.
:
: This patch enables configuring a system so that a runaway job under one
: mem_exclusive cpuset cannot cause the killing of a job in another such cpuset
: that might be using very high compute and memory resources for a prolonged
: time.
And we changed it to current logic in 2006
: commit 7887a3da753e1ba8244556cc9a2b38c815bfe256
: Author: Nick Piggin <npiggin@xxxxxxx>
: Date: Mon Sep 25 23:31:29 2006 -0700
:
: [PATCH] oom: cpuset hint
:
: cpuset_excl_nodes_overlap does not always indicate that killing a task will
: not free any memory we for us. For example, we may be asking for an
: allocation from _anywhere_ in the machine, or the task in question may be
: pinning memory that is outside its cpuset. Fix this by just causing
: cpuset_excl_nodes_overlap to reduce the badness rather than disallow it.
And we haven't get the explanation why this patch doesn't reintroduced
an old issue.
I don't refuse a patch if it have multiple ack. But if you have any
material or number, please show us soon.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>