From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758017AbZEDPWm (ORCPT ); Mon, 4 May 2009 11:22:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757024AbZEDPU3 (ORCPT ); Mon, 4 May 2009 11:20:29 -0400 Received: from mail-ew0-f224.google.com ([209.85.219.224]:42007 "EHLO mail-ew0-f224.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757368AbZEDPU2 (ORCPT ); Mon, 4 May 2009 11:20:28 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=LldCaSQRz+rbWgCvVXZMxzWzAmIiAu45FPMYDjeM6ZZd3NDj2gMdV0Ooi5IbrwBVlj cPcJqK5phvLCNT1btLpbTfagalAIw7Gpkcm/Eu3IPbqMWd2B8KPLN3KVksJ/mG2b++Gk Gzxz9WDAxVIjdUKtGr2mDDoTL/v8MVGfMkcnM= Date: Mon, 4 May 2009 19:20:26 +0400 From: Cyrill Gorcunov To: Christoph Lameter , Ingo Molnar , Andrew Morton , Mel Gorman , LKML , Pekka Enberg , Rik van Riel , David Rientjes , Pavel Emelyanov Subject: Re: [PATCH -tip] mm: introduce __GFP_PANIC modifier Message-ID: <20090504152026.GO4173@lenovo> References: <20090504122740.GH4173@lenovo> <20090504131311.GA23330@elte.hu> <20090504131638.GJ4173@lenovo> <20090504141256.GK4173@lenovo> <20090504142903.GM4173@lenovo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090504142903.GM4173@lenovo> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [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