From: "Chad Zanonie" <chad.zanonie@gmail.com>
To: "Oleg Nesterov" <oleg@tv-sign.ru>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
npiggin@suse.de, rientjes@google.com
Subject: Re: + mm-oom-killer-kills-more-than-needed.patch added to -mm tree
Date: Tue, 23 Sep 2008 10:37:52 -0700 [thread overview]
Message-ID: <2137b82d0809231037w3900ef3fta003b791bf36d4a@mail.gmail.com> (raw)
In-Reply-To: <2137b82d0809231025n359b3f59h53714d5acabd2107@mail.gmail.com>
Before I propagate this blunder anymore, I've found the root of my mistake.
I really mean TASK_DEAD, not EXIT_DEAD.
(p->state & TASK_DEAD)
-Chad
On Tue, Sep 23, 2008 at 10:25 AM, Chad Zanonie <chad.zanonie@gmail.com> wrote:
> On Tue, Sep 23, 2008 at 5:40 AM, Oleg Nesterov <oleg@tv-sign.ru> wrote:
>> On 09/22, Andrew Morton wrote:
>>>
>>> ------------------------------------------------------
>>> Subject: mm: oom-killer kills more than needed
>>> From: "Chad Zanonie" <chad.zanonie@gmail.com>
>>>
>>> Possibility exists for an exiting application to be in between marking its
>>> mm NULL and calling mmput when out_of_memory is invoked.
>>> select_bad_process() will continue past this process as opposed to
>>> returning -1UL due to its mm being NULL. This causes the oom killer in
>>> certain scenarios to not only kill the memory culprit, but also kill the
>>> runner up.
>>>
>>> EXIT_DEAD seems to be the only flag that guarantees that mmput() has
>>> finished.
>>
>> I don't think this is right.
>>
>> Let's suppose we have a single zombie. Now select_bad_process() always
>> returns -1 ? IOW, doesn't this means that, say,
>>
>> $ perl -e 'fork && sleep'
>>
>> disables oom-kill completely and forever?
>
> Ugh, looks like my description was slightly incorrect. I don't mean
> for it to return -1 upon noticing a null mm. I mean for
> select_bad_process to not skip (continue) over processes that haven't
> provably finished unmapping their memory (which EXIT_DEAD infers).
>
>>
>> Hmm. But please see below. This doesn't happen because the usage
>> of EXIT_DEAD is not right.
>>
>>> Checking for PF_KTHREAD should replace p->mm regardless.
>>
>> Yes, almost every check for ->mm in oom_kill.c is not right.
>>
>>> Adding EXIT_DEAD to the check seems to prevent unnecessary kills in local
>>> testing.
>>
>> This is strange, could you re-test? Because
>>
>>> @@ -216,7 +216,7 @@ static struct task_struct *select_bad_pr
>>> * skip kernel threads and tasks which have already released
>>> * their mm.
>>> */
>>> - if (!p->mm)
>>> + if (p->flags & PF_KTHREAD || p->flags & EXIT_DEAD)
>> ^^^^^^^^^^^^^^^^^
>>
>> this is not possible. EXIT_DEAD lives in ->exit_state, not in ->flags.
>
> Good catch. I had actually done the testing in an older kernel that
> used PF_DEAD and while noticing the change to only EXIT_DEAD forgot to
> use the new appropriate flag in the patch.
>
>>
>> Oleg.
>>
>>
>
> I'm new to this endeavor. Should I propose a new patch, or, will
> things be fixed from this omission? I still support the EXIT_DEAD
> inclusion, as it'll allow the OOM killer to make the similar progress
> that !p->mm provided.
>
> Chad
>
next prev parent reply other threads:[~2008-09-23 17:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200809222238.m8MMcgAp001695@imap1.linux-foundation.org>
2008-09-23 12:40 ` + mm-oom-killer-kills-more-than-needed.patch added to -mm tree Oleg Nesterov
2008-09-23 17:25 ` Chad Zanonie
2008-09-23 17:37 ` Chad Zanonie [this message]
2008-09-24 16:58 ` Oleg Nesterov
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=2137b82d0809231037w3900ef3fta003b791bf36d4a@mail.gmail.com \
--to=chad.zanonie@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=oleg@tv-sign.ru \
--cc=rientjes@google.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