From: Zackary Liu <zackary.liu.pro@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/oom_kill: break evaluation when a task has been selected
Date: Sat, 4 Jun 2022 18:35:19 +0800 [thread overview]
Message-ID: <6BC32F66-2AC4-450D-90D5-B7A09455B617@getmailspring.com> (raw)
In-Reply-To: <YpcZFvVZRPTyTQ7s@dhcp22.suse.cz>
On Jun 1 2022, at 3:45 pm, Michal Hocko <mhocko@suse.com> wrote:
> On Sat 14-05-22 15:52:28, Zhaoyu Liu wrote:
>> oom points no longer need to be calculated if a task is oom_task_origin(),
>> so return 1 to stop the oom_evaluate_task().
>
> This doesn't really explain why this is really desired. Is this a fix,
> optimization?
>
> Please also note that this change has some side effects. For one, the
> task marked as oom origin will get killed even if there is still a
> pending oom victim which hasn't been fully dismantled. Is this
> intentional?
Thank you very much for reminding.
From my point of view, the victim was marked in the last oom, and now it
has entered the oom again, which means that the system still has no
deprecated memory available. In order to ensure that the system can
return to normal as soon as possible, killing the origin task
immediately should be A good choice, and the role of this patch is to
end oom_evaluate_task and return true as soon as the origin task is found.
Maybe this patch is not the optimal solution, it has a trade-off.
It is an honor to discuss with you, thank you very much!
zackary
>> Signed-off-by: Zhaoyu Liu <zackary.liu.pro@gmail.com>
>> ---
>> mm/oom_kill.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
>> index 3996301450e8..b407fba21d19 100644
>> --- a/mm/oom_kill.c
>> +++ b/mm/oom_kill.c
>> @@ -308,7 +308,7 @@ static enum oom_constraint
>> constrained_alloc(struct oom_control *oc)
>> static int oom_evaluate_task(struct task_struct *task, void *arg)
>> {
>> struct oom_control *oc = arg;
>> - long points;
>> + long points = 0;
>>
>> if (oom_unkillable_task(task))
>> goto next;
>> @@ -349,7 +349,7 @@ static int oom_evaluate_task(struct task_struct
>> *task, void *arg)
>> oc->chosen = task;
>> oc->chosen_points = points;
>> next:
>> - return 0;
>> + return points == LONG_MAX;
>> abort:
>> if (oc->chosen)
>> put_task_struct(oc->chosen);
>> --
>> 2.17.1
>
> --
> Michal Hocko
> SUSE Labs
>
next prev parent reply other threads:[~2022-06-04 10:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-14 7:52 Zhaoyu Liu
2022-06-01 7:45 ` Michal Hocko
2022-06-04 10:35 ` Zackary Liu [this message]
2022-06-06 8:33 ` Michal Hocko
2022-06-14 7:48 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6BC32F66-2AC4-450D-90D5-B7A09455B617@getmailspring.com \
--to=zackary.liu.pro@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox