Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Waiman Long <llong@redhat.com>
Subject: Re: [RFC PATCH] mm/oom_kill: allow oom kill allocating task for
 non-global case
To:     Shakeel Butt <shakeelb@google.com>, Waiman Long <llong@redhat.com>
Cc:     Aaron Tomlin <atomlin@redhat.com>, Linux MM <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        Michal Hocko <mhocko@suse.com>,
        LKML <linux-kernel@vger.kernel.org>
References: <20210607163103.632681-1-atomlin@redhat.com>
 <c16893a9-35e2-7625-d7f3-83488f874040@redhat.com>
 <CALvZod4eUoquGTQ5AsWgbWTQyqtCNNwb-9+fRw_ZPavH-r9dbA@mail.gmail.com>
Message-ID: <dc7f54eb-933e-5bbb-7959-815dfbfcc836@redhat.com>
Date:   Mon, 7 Jun 2021 14:51:05 -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: <CALvZod4eUoquGTQ5AsWgbWTQyqtCNNwb-9+fRw_ZPavH-r9dbA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 6/7/21 2:43 PM, Shakeel Butt wrote:
> On Mon, Jun 7, 2021 at 9:45 AM Waiman Long <llong@redhat.com> 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 "allocating"
>>> task cannot be selected, as a target for the OOM killer.
>>>
>>> This patch removes the restriction entirely.
>>>
>>> Signed-off-by: Aaron Tomlin <atomlin@redhat.com>
>>> ---
>>>    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;
>> To provide more context for this patch, we are actually seeing that in a
>> 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.
> Why was there no killable process? What about the process allocating
> 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 
killing them won't free up that much.

The other process that uses most of the memory is the one that trigger 
the OOM kill in the first place because the memory limit has been 
reached in new memory allocation. Based on the current logic, this 
process cannot be killed at all even if we set the 
oom_kill_allocating_task to 1 if the OOM happens only within the memcg 
context, not in a global OOM situation. This patch is to allow this 
process to be killed under this circumstance.

Cheers,
Longman