From: Dave Hansen <dave@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Nick Piggin <npiggin@suse.de>, Mel Gorman <mel@csn.ul.ie>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Christoph Lameter <cl@linux-foundation.org>,
San Mehat <san@android.com>, Arve Hjonnevag <arve@android.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch 08/11 -mmotm] oom: invoke oom killer for __GFP_NOFAIL
Date: Mon, 11 May 2009 09:03:13 -0700 [thread overview]
Message-ID: <1242057793.8109.34342.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.DEB.2.00.0905110143190.24726@chino.kir.corp.google.com>
On Mon, 2009-05-11 at 01:45 -0700, David Rientjes wrote:
> On Mon, 11 May 2009, KOSAKI Motohiro wrote:
> include/linux/gfp.h states this:
>
> * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
> * cannot handle allocation failures.
>
> That is the only desciption given to users of __GFP_NOFAIL, so they should
> be able to trust it. The fact is that in mmotm it's possible for such an
> allocation to fail without even attempting to free some memory via the oom
> killer (and I disagree that killing a large memory hogging task will not
> allow large allocations such as those greater than PAGE_ALLOC_COSTLY_ORDER
> to succeed, which is a question of fragmentation and not purely VM size).
I assume that you've actually seen this behavior where OOM-killing a
task will free enough memory to allow a higher-order allocation to
succeed.
Could you explain a little more about why you think this scenario works
for you? Are large contiguous areas of memory pinned by the task
getting which you want to get killed? Why wasn't swapping effective
against this task? Was the task itself taking up a large portion of
total memory?
-- Dave
next prev parent reply other threads:[~2009-05-11 16:03 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-10 22:07 [patch 01/11 -mmotm] lowmemorykiller: Only iterate over process list when needed David Rientjes
2009-05-10 22:07 ` [patch 02/11 -mmotm] lowmemorykiller: Don't count free space unless it meets the specified limit by itself David Rientjes
2009-05-12 9:23 ` Mel Gorman
2009-05-13 0:27 ` Arve Hjønnevåg
2009-05-13 9:42 ` Mel Gorman
2009-05-14 23:25 ` Arve Hjønnevåg
2009-05-15 9:18 ` Mel Gorman
2009-05-10 22:07 ` [patch 03/11 -mmotm] oom: cleanup android low memory killer David Rientjes
2009-05-10 22:07 ` [patch 04/11 -mmotm] oom: fix possible android low memory killer NULL pointer David Rientjes
2009-05-10 22:07 ` [patch 05/11 -mmotm] oom: fix possible oom_dump_tasks " David Rientjes
2009-05-11 21:11 ` Andrew Morton
2009-05-11 21:28 ` David Rientjes
2009-05-11 21:41 ` Greg KH
2009-05-11 22:05 ` David Rientjes
2009-05-12 9:38 ` Mel Gorman
2009-05-10 22:07 ` [patch 06/11 -mmotm] oom: move oom_adj value from task_struct to mm_struct David Rientjes
2009-05-11 0:17 ` KOSAKI Motohiro
2009-05-11 0:26 ` David Rientjes
2009-05-11 1:47 ` KOSAKI Motohiro
2009-05-11 8:43 ` David Rientjes
2009-05-11 21:19 ` Andrew Morton
2009-05-12 9:56 ` Mel Gorman
2009-05-10 22:07 ` [patch 07/11 -mmotm] oom: prevent possible OOM_DISABLE livelock David Rientjes
2009-05-11 21:22 ` Andrew Morton
2009-05-10 22:07 ` [patch 08/11 -mmotm] oom: invoke oom killer for __GFP_NOFAIL David Rientjes
2009-05-10 23:59 ` KOSAKI Motohiro
2009-05-11 0:24 ` David Rientjes
2009-05-11 1:45 ` KOSAKI Motohiro
2009-05-11 7:40 ` Minchan Kim
2009-05-11 8:49 ` David Rientjes
2009-05-11 11:23 ` Minchan Kim
2009-05-11 8:45 ` David Rientjes
2009-05-11 16:03 ` Dave Hansen [this message]
2009-05-11 19:09 ` David Rientjes
2009-05-11 19:45 ` Dave Hansen
2009-05-11 20:21 ` David Rientjes
2009-05-11 21:29 ` Andrew Morton
2009-05-11 21:45 ` David Rientjes
2009-05-11 22:11 ` Andrew Morton
2009-05-11 22:31 ` David Rientjes
2009-05-11 22:46 ` Andrew Morton
2009-05-11 23:00 ` David Rientjes
2009-05-11 23:14 ` Andrew Morton
2009-05-11 23:37 ` David Rientjes
2009-05-12 5:39 ` Peter Zijlstra
2009-05-12 11:36 ` KOSAKI Motohiro
2009-05-12 10:05 ` Mel Gorman
2009-05-10 22:07 ` [patch 09/11 -mmotm] oom: return vm size of oom killed task David Rientjes
2009-05-11 21:36 ` Andrew Morton
2009-05-10 22:07 ` [patch 10/11 -mmotm] oom: avoid oom kill if no interruptible tasks David Rientjes
2009-05-11 21:39 ` Andrew Morton
2009-05-11 23:08 ` David Rientjes
2009-05-10 22:07 ` [patch 11/11 -mmotm] oom: fail allocations if oom killer can't free memory David Rientjes
2009-05-12 21:14 ` Misleading OOM messages Christoph Lameter
2009-05-14 9:29 ` Pavel Machek
2009-05-14 19:46 ` Christoph Lameter
2009-05-14 20:38 ` Dave Hansen
2009-05-14 20:49 ` Christoph Lameter
2009-05-14 20:49 ` David Rientjes
2009-05-14 21:05 ` Dave Hansen
2009-05-14 21:12 ` David Rientjes
2009-05-14 21:30 ` Christoph Lameter
2009-05-14 21:34 ` Pavel Machek
2009-05-14 21:41 ` Dave Hansen
2009-05-15 13:05 ` Pavel Machek
2009-05-15 17:59 ` Christoph Lameter
2009-05-15 18:22 ` Dave Hansen
2009-05-15 19:29 ` Christoph Lameter
2009-05-15 20:02 ` Pavel Machek
2009-05-15 21:15 ` Christoph Lameter
2009-05-19 20:39 ` Pavel Machek
2009-05-22 13:53 ` Christoph Lameter
2009-05-22 14:17 ` Warn when we run out of swap space (was Re: Misleading OOM messages) Christoph Lameter
2009-05-22 14:56 ` Pavel Machek
2009-05-22 19:01 ` Misleading OOM messages Christoph Lameter
2009-05-22 19:40 ` Randy Dunlap
2009-05-22 19:44 ` Christoph Lameter
2009-05-22 21:45 ` Alan Cox
2009-05-22 21:43 ` Alan Cox
2009-05-15 17:57 ` Christoph Lameter
2009-05-15 18:15 ` Dave Hansen
2009-05-15 18:19 ` Balbir Singh
2009-05-15 19:26 ` Christoph Lameter
2009-05-15 20:31 ` Balbir Singh
2009-05-18 14:34 ` Christoph Lameter
2009-05-18 15:45 ` Balbir Singh
2009-05-14 21:37 ` Dave Hansen
2009-05-14 22:00 ` David Rientjes
2009-05-15 17:58 ` Christoph Lameter
2009-05-15 18:23 ` Dave Hansen
2009-05-15 18:57 ` Balbir Singh
2009-05-15 19:37 ` David Rientjes
2009-05-14 20:56 ` Pavel Machek
2009-05-12 9:09 ` [patch 01/11 -mmotm] lowmemorykiller: Only iterate over process list when needed Mel Gorman
2009-05-13 0:43 ` Arve Hjønnevåg
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=1242057793.8109.34342.camel@localhost.localdomain \
--to=dave@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arve@android.com \
--cc=cl@linux-foundation.org \
--cc=gregkh@suse.de \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=npiggin@suse.de \
--cc=rientjes@google.com \
--cc=san@android.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