From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15B4FC47094 for ; Mon, 7 Jun 2021 20:45:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8BB3061139 for ; Mon, 7 Jun 2021 20:45:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BB3061139 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 273DC6B0070; Mon, 7 Jun 2021 16:45:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24AAC6B0071; Mon, 7 Jun 2021 16:45:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C4386B0072; Mon, 7 Jun 2021 16:45:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id D19D66B0070 for ; Mon, 7 Jun 2021 16:45:05 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7D6571AD9A for ; Mon, 7 Jun 2021 20:45:05 +0000 (UTC) X-FDA: 78228107370.13.E5831A4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 9FDEE4001B1F for ; Mon, 7 Jun 2021 20:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623098568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NVFE7839wJQhjfwahJMzdYuo8c3wA2maMZqOHJgIOFI=; b=QarT1CzEuOkpjEGqWFWFx6JcBGuqzzEi6frUm15o/GBOK5NNSqEMAWc4ZUBS8gjeZYtkC5 aIt6aXCuTS4EBth5Fg1aA09f1BqYlKiaOF5SShqOwED+b2HmBZeLqkbycrIcbl9VZkwaX8 ljtuy0uMsDSlqskvrb/jAcrcc/oLq2g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623098582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NVFE7839wJQhjfwahJMzdYuo8c3wA2maMZqOHJgIOFI=; b=QP6dOwOpxZInFZK91zmf+g/a7kI5CJ0DSHzYOA49YHZsQvxiG0nt7+P4BVGJxS99VeCIHn Uu5HJkP+wGI1ndfUXE5wWHqZaSBUrZEJAPic+ZMb9M/Ndd5ApaxhmJ+YVe14QNQNZvjgSw nq6Cni+wTeY9g27D5ZQQ2fyCwmPKy8E= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-374-B1r5qqukPD-zFZeaaLGxoQ-1; Mon, 07 Jun 2021 16:42:42 -0400 X-MC-Unique: B1r5qqukPD-zFZeaaLGxoQ-1 Received: by mail-qv1-f71.google.com with SMTP id jm5-20020ad45ec50000b0290219dc9a1ab8so3674128qvb.21 for ; Mon, 07 Jun 2021 13:42:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=NVFE7839wJQhjfwahJMzdYuo8c3wA2maMZqOHJgIOFI=; b=WG0clyfOjUDmF61/rg4rSoMkSvxT9PNGShvr6xVhLPsXE5nKOQGUN8bYu7V/X3xun6 o/Lcn/s6CbqvN3CWQkd5GBNIiEsRe+R5bT/ix83WSpUJ3CGf0WRzwR6cCdIfJWKMEltF CumlRuE2v19pUadzEPMQgUZXC4kdugrGygc+7G1bDk3ILSRwNet3keCUB/BboHhOq3V2 gUp1WnfI463hOY7bNmp5XGsj25Y/LrIqaa/QeKdWjZPt9RGf5D8082RWxjVrsaiM38tz mQc0aEGQcn40tJk3AcfT7efMJFTWTW4WcnEEeuR8WqtLp9XSDse+RGtS27/tQPL1vQoR xe/Q== X-Gm-Message-State: AOAM531XKgWihIajRkJ7TU4k7mXrUVM8lhOWx2V7bDCbzWoYGAdPBY6t kLE26MQNvuyXfGdrDT5A3qHQPjwWqlzbEKWK0I19K8c8Shw13Mbpzi3orU7KqDfS59zNvlXFVYS o+t6U7yanSh8= X-Received: by 2002:a0c:fe62:: with SMTP id b2mr10248167qvv.30.1623098562248; Mon, 07 Jun 2021 13:42:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPGiyG0OmvYR1j1nFCrdaT6qA4VcsQUJmpVnS8bNZMG/6o6Hu9CB31bkiDtvlU9zNTuK+yaw== X-Received: by 2002:a0c:fe62:: with SMTP id b2mr10248151qvv.30.1623098562066; Mon, 07 Jun 2021 13:42:42 -0700 (PDT) Received: from llong.remote.csb ([2601:191:8500:76c0::cdbc]) by smtp.gmail.com with ESMTPSA id u123sm7330177qkh.83.2021.06.07.13.42.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 13:42:41 -0700 (PDT) From: Waiman Long X-Google-Original-From: Waiman Long Subject: Re: [RFC PATCH] mm/oom_kill: allow oom kill allocating task for non-global case To: Michal Hocko , Waiman Long Cc: Shakeel Butt , Aaron Tomlin , Linux MM , Andrew Morton , Vlastimil Babka , LKML References: <20210607163103.632681-1-atomlin@redhat.com> <6d23ce58-4c4b-116a-6d74-c2cf4947492b@redhat.com> Message-ID: Date: Mon, 7 Jun 2021 16:42:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QarT1CzE; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QP6dOwOp; spf=none (imf02.hostedemail.com: domain of llong@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=llong@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: wysyg7784bbh87on6fdfuc4dt7yruofr X-Rspamd-Queue-Id: 9FDEE4001B1F X-Rspamd-Server: rspam06 X-HE-Tag: 1623098586-807141 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/7/21 3:36 PM, Michal Hocko wrote: > On Mon 07-06-21 15:18:38, Waiman Long wrote: >> On 6/7/21 3:04 PM, Michal Hocko wrote: >>> On Mon 07-06-21 14:51:05, Waiman Long wrote: >>>> On 6/7/21 2:43 PM, Shakeel Butt wrote: >>>>> On Mon, Jun 7, 2021 at 9:45 AM Waiman Long wrote= : >>>>>> On 6/7/21 12:31 PM, Aaron Tomlin wrote: >>>>>>> At the present time, in the context of memcg OOM, even when >>>>>>> sysctl_oom_kill_allocating_task is enabled/or set, the "allocatin= g" >>>>>>> task cannot be selected, as a target for the OOM killer. >>>>>>> >>>>>>> This patch removes the restriction entirely. >>>>>>> >>>>>>> Signed-off-by: Aaron Tomlin >>>>>>> --- >>>>>>> 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 =3D 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 !=3D OOM_SCORE_ADJ_MI= N) { >>>>>>> get_task_struct(current); >>>>>>> oc->chosen =3D current; >>>>>> To provide more context for this patch, we are actually seeing tha= t in a >>>>>> customer report about OOM happened in a container where the domina= ting >>>>>> task used up most of the memory and it happened to be the task tha= t >>>>>> triggered the OOM with the result that no killable process could b= e >>>>>> found. >>>>> Why was there no killable process? What about the process allocatin= g >>>>> the memory or is this remote memcg charging? >>>> It is because the other processes have a oom_adjust_score of -1000. = So they >>>> are non-killable. Anyway, they don't consume that much memory and ki= lling >>>> them won't free up that much. >>>> >>>> The other process that uses most of the memory is the one that trigg= er the >>>> OOM kill in the first place because the memory limit has been reache= d in new >>>> memory allocation. Based on the current logic, this process cannot b= e killed >>>> at all even if we set the oom_kill_allocating_task to 1 if the OOM h= appens >>>> only within the memcg context, not in a global OOM situation. This p= atch is >>>> to allow this process to be killed under this circumstance. >>> Do you have the oom report? I do not see why the allocating task hasn= 't >>> been chosen. >> A partial OOM report below: > Do you happen to have the full report? I need to ask to see if I can release the full report. > >> [ 8221.433608] memory: usage 21280kB, limit 204800kB, failcnt 49116 >> =C2=A0 : >> [ 8227.239769] [ pid ]=C2=A0=C2=A0 uid=C2=A0 tgid total_vm=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 rss pgtables_bytes swapents oom_score_adj name >> [ 8227.242495] [1611298]=C2=A0=C2=A0=C2=A0=C2=A0 0 1611298=C2=A0=C2=A0= =C2=A0 35869=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 635 167936=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -= 1000 conmon >> [ 8227.242518] [1702509]=C2=A0=C2=A0=C2=A0=C2=A0 0 1702509=C2=A0=C2=A0= =C2=A0 35869=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 701 176128=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -= 1000 conmon >> [ 8227.242522] [1703345] 1001050000 1703294=C2=A0=C2=A0 183440=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 2125824=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 999 node >> [ 8227.242706] Out of memory and no killable processes... >> [ 8227.242731] node invoked oom-killer: gfp_mask=3D0x6000c0(GFP_KERNEL= ), nodemask=3D(null), order=3D0, oom_score_adj=3D999 >> [ 8227.242732] node cpuset=3Dcrio-b8ac7e23f7b520c0365461defb6673823191= 8243586e287bfb9e206bb3a0227a.scope mems_allowed=3D0-1 >> >> So in this case, node cannot kill itself and no other processes are >> available to be killed. > The process is clearly listed as eligible so the oom killer should find > it and if it hasn't then this should be investigated. Which kernel is > this? Right. I don't know why the current cannot be selected. I think we may=20 need to enhance the OOM but no killable process report to list the=20 reason a task is skipped other than oom_score_adj. The kernel is a=20 RHEL8.2 kernel which has OOM code pretty close to upstream. Cheers, Longman