[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090504152026.GO4173@lenovo>
Date: Mon, 4 May 2009 19:20:26 +0400
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Christoph Lameter <cl@...ux.com>, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mel@....ul.ie>,
LKML <linux-kernel@...r.kernel.org>,
Pekka Enberg <penberg@...helsinki.fi>,
Rik van Riel <riel@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [PATCH -tip] mm: introduce __GFP_PANIC modifier
[Cyrill Gorcunov - Mon, May 04, 2009 at 06:29:03PM +0400]
| [Christoph Lameter - Mon, May 04, 2009 at 10:13:34AM -0400]
| | On Mon, 4 May 2009, Cyrill Gorcunov wrote:
| |
| | > As I see page allocator already quite modified in -mm tree.
| | > Christoph will kmalloc with (__GFP_NOFAIL | __GFP_REPEAT)
| | > inform us on exhausted memory? Or we just stuck with blank
| | > screen instead (not blank actually but with previous messages)?
| |
| | If you do not specify __GFP_NOWARN then it should give you messages,
| |
| | Guess we need to very that it behaves in the right wya.
| |
|
| thanks Christoph, I need to read a modified version (which
| is in -mm tree now). Maybe we could find a way indeed :)
|
| -- Cyrill
You know I only found a message in case if page is already
not granted (ie NULL is going to be returned) and right
before that we print a warning about that (nopage: label).
Which means - no panic here and with (__GFP_NOFAIL | __GFP_REPEAT)
just spinning around in attepmt to allocate new memory. And how
to behave on atomic allocations. Almost give up... :)
-- Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists