From: Andrew Morton <akpm@linux-foundation.org>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andrey Vagin <avagin@openvz.org>
Subject: Re: [PATCH] Accelerate OOM killing
Date: Wed, 30 Mar 2011 14:36:17 -0700 [thread overview]
Message-ID: <20110330143617.3d57aad2.akpm@linux-foundation.org> (raw)
In-Reply-To: <1300960353-2596-1-git-send-email-minchan.kim@gmail.com>
On Thu, 24 Mar 2011 18:52:33 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> When I test Andrey's problem, I saw the livelock and sysrq-t says
> there are many tasks in cond_resched after try_to_free_pages.
__alloc_pages_direct_reclaim() has two cond_resched()s, in
straight-line code. So I think you're concluding that the first
cond_resched() is a no-op, but the second one frequently schedules
away.
For this to be true, the try_to_free_pages() call must be doing
something to cause it, such as taking a large amount of time, or
delivering wakeups, etc. Do we know?
The patch is really a bit worrisome and ugly. If the CPU scheduler has
decided that this task should be preempted then *that* is the problem,
and we need to work out why it is happening and see if there is anything
we should fix. Instead the patch simply ignores the scheduler's
directive, which is known as "papering over a bug".
IOW, we should work out why need_resched is getting set so frequently
rather than just ignoring it (and potentially worsening kernel
scheduling latency).
> If did_some_progress is false, cond_resched could delay oom killing so
> It might be killing another task.
>
> This patch accelerates oom killing without unnecessary giving CPU
> to another task. It could help avoding unnecessary another task killing
> and livelock situation a litte bit.
Well... _does_ it help? What were the results of your testing of this
patch?
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-03-30 21:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 9:52 [PATCH] Accelerate OOM killing Minchan Kim
2011-03-24 10:05 ` KOSAKI Motohiro
2011-03-24 21:47 ` David Rientjes
2011-03-24 23:35 ` KAMEZAWA Hiroyuki
2011-03-30 21:36 ` Andrew Morton [this message]
2011-03-30 22:54 ` Minchan Kim
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=20110330143617.3d57aad2.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=avagin@openvz.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.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).