Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754475Ab0HZWbd (ORCPT ); Thu, 26 Aug 2010 18:31:33 -0400 Received: from smtp-out.google.com ([216.239.44.51]:6777 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752432Ab0HZWba (ORCPT ); Thu, 26 Aug 2010 18:31:30 -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=HEARnNd4p5hZzV3E/8aKfAxNaWUuk94RjZt444GmCH5hC/CDgBOYZZ08RFIS9v2K+ HAH6s4CFz03uIP/xl7R6w== Date: Thu, 26 Aug 2010 15:31:22 -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: 1144 Lines: 23 On Thu, 26 Aug 2010, Christoph Lameter wrote: > > Because we can remove the flag, remove branches from the page allocator > > slowpath, and none of these allocations actually are dependent on > > __GFP_NOFAIL since they are all under PAGE_ALLOC_COSTLY_ORDER. > > Then we can simply remove __GFP_NOFAIL? Functions are only needed for > higher order allocs that can fail? > Yes, that's the intent. We'd like to add the WARN_ON_ONCE(get_order(size) >= PAGE_ALLOC_COSTLY_ORDER) warning, though, so we're ensured that redefinition of that #define doesn't cause allocations to fail to that don't have appropriate error handling or future callers use higher order allocs. The _nofail() functions help that and do some due diligence in ensuring that we aren't changing gfp flags based only on the current page allocator implementation which may later change with very specialized corner cases. -- 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/