On Mon, Jun 7, 2021 at 9:45 AM Waiman Long <llong@xxxxxxxxxx> wrote:
On 6/7/21 12:31 PM, Aaron Tomlin wrote:Why was there no killable process? What about the process allocating
At the present time, in the context of memcg OOM, even whenTo provide more context for this patch, we are actually seeing that in a
sysctl_oom_kill_allocating_task is enabled/or set, the "allocating"
task cannot be selected, as a target for the OOM killer.
This patch removes the restriction entirely.
Signed-off-by: Aaron Tomlin <atomlin@xxxxxxxxxx>
---
mm/oom_kill.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index eefd3f5fde46..3bae33e2d9c2 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1089,9 +1089,9 @@ bool out_of_memory(struct oom_control *oc)
oc->nodemask = NULL;
check_panic_on_oom(oc);
- if (!is_memcg_oom(oc) && sysctl_oom_kill_allocating_task &&
- current->mm && !oom_unkillable_task(current) &&
- oom_cpuset_eligible(current, oc) &&
+ if (sysctl_oom_kill_allocating_task && current->mm &&
+ !oom_unkillable_task(current) &&
+ oom_cpuset_eligible(current, oc) &&
current->signal->oom_score_adj != OOM_SCORE_ADJ_MIN) {
get_task_struct(current);
oc->chosen = current;
customer report about OOM happened in a container where the dominating
task used up most of the memory and it happened to be the task that
triggered the OOM with the result that no killable process could be
found.
the memory or is this remote memcg charging?