From: Andrew Morton <akpm@osdl.org>
To: Dave Peterson <dsp@llnl.gov>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
riel@surriel.com, nickpiggin@yahoo.com.au, ak@suse.de
Subject: Re: [PATCH 1/2 (repost)] mm: serialize OOM kill operations
Date: Thu, 27 Apr 2006 15:56:13 -0700 [thread overview]
Message-ID: <20060427155613.15d565b1.akpm@osdl.org> (raw)
In-Reply-To: <200604271308.10080.dsp@llnl.gov>
Dave Peterson <dsp@llnl.gov> wrote:
>
> The patch below modifies the behavior of the OOM killer so that only
> one OOM kill operation can be in progress at a time. When running a
> test program that eats lots of memory, I was observing behavior where
> the OOM killer gets impatient and shoots one or more system daemons
> in addition to the program that is eating lots of memory. This fixes
> the problematic behavior.
>
> ...
>
> @@ -379,6 +380,15 @@ void mmput(struct mm_struct *mm)
> spin_unlock(&mmlist_lock);
> }
> put_swap_token(mm);
> +
> + if (unlikely(test_bit(MM_FLAG_OOM_NOTIFY, &mm->flags)))
> + /* Terminate a pending OOM kill operation. No tasks
> + * actually spin on the lock. Tasks only do
> + * spin_trylock() (and abort OOM kill operation if
> + * lock is already taken).
> + */
> + spin_unlock(&oom_kill_lock);
> +
Gad. I guess if we're going to do this then a better implementation would
be to use test_and_set_bit(some_unsigned_long). And perhaps call some
oom_kill.c interface function here rather than directly accessing
oom-killer data structures (could be an inlined function).
But the broader question is "what do we want to do here".
If we've picked a task and we've signalled it then the right thing to do
would appear to be just to block all tasks as they enter the oom-killer.
Send them to sleep until the killed task actually exits. But
a) memory can become free (or reclaimable) for other reasons, so those
now-sleeping tasks shouldn't be sleeping any more (this is a minor
problem).
b) one of the sleeping tasks may be holding a lock which prevents the
killed task from reaching do_exit(). This is a showstopper.
But I think b) stops your show as well:
- task A enters the oom-killer, decides to kill task Z.
- task A holds a lock which is preventing task Z from exitting
- but oom_kill_lock is now held. task A just keeps on trying to reclaim
memory and trying (and failing) to kill tasks.
- user hits reset button.
IOW: we just have to keep killing more tasks until something happens.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-04-27 22:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-27 20:08 [PATCH 1/2 (repost)] mm: serialize OOM kill operations Dave Peterson
2006-04-27 20:44 ` Paul Jackson
2006-04-27 21:09 ` Andrew Morton
2006-04-27 21:32 ` Dave Peterson
2006-04-27 23:02 ` Paul Jackson
2006-04-28 22:09 ` Dave Peterson
2006-04-27 22:56 ` Andrew Morton [this message]
2006-04-28 21:59 ` Dave Peterson
2006-04-28 22:16 ` Andrew Morton
2006-04-28 22:24 ` Dave Peterson
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=20060427155613.15d565b1.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ak@suse.de \
--cc=dsp@llnl.gov \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=riel@surriel.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;
as well as URLs for NNTP newsgroup(s).