Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754563Ab0HYVXh (ORCPT ); Wed, 25 Aug 2010 17:23:37 -0400 Received: from smtp-out.google.com ([74.125.121.35]:61245 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754466Ab0HYVXd (ORCPT ); Wed, 25 Aug 2010 17:23:33 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=lLwXeMY+IJdWw3wNk1GOzOfIXXN9Lcho/ajDFTC7eqAI1IipBik/3iDn/YrTXuG2t ji/6SfSUd0sKol0V4LR/Q== Date: Wed, 25 Aug 2010 14:23:26 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Christoph Lameter cc: Peter Zijlstra , Dave Chinner , "Ted Ts'o" , Jens Axboe , Andrew Morton , Neil Brown , Alasdair G Kergon , Chris Mason , Steven Whitehouse , Jan Kara , Frederic Weisbecker , "linux-raid@vger.kernel.org" , "linux-btrfs@vger.kernel.org" , "cluster-devel@redhat.com" , "linux-ext4@vger.kernel.org" , "reiserfs-devel@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc In-Reply-To: Message-ID: References: <1282656558.2605.2742.camel@laptop> <4C73CA24.3060707@fusionio.com> <20100825112433.GB4453@thunk.org> <1282736132.2605.3563.camel@laptop> <20100825115709.GD4453@thunk.org> <1282740516.2605.3644.camel@laptop> <20100825132417.GQ31488@dastard> <1282743342.2605.3707.camel@laptop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 990 Lines: 20 On Wed, 25 Aug 2010, Christoph Lameter wrote: > We already have __GFP_NOFAIL behavior for slab allocations since > a __GFP_NOFAIL flag is passed through to the page allocator if no objects > are available. > It all depends on what flags are passed to kmalloc(), slab nor slub enforce __GFP_NOFAIL behavior themselves. In slab, cache_grow() will return NULL depending on whether the page allocator returns NULL, and that would only happen for __GFP_NORETRY or cachep->gfp->gfporder >= PAGE_ALLOC_COSTLY_ORDER. In slub, the default order is tried with __GFP_NORETRY and if it returns NULL, the higher order alloc will fail under the same circumstances. So the nofail behavior for slab depends only on the flags passed from the caller. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/