From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK From: Peter Zijlstra In-Reply-To: <20070723113712.c0ee29e5.akpm@linux-foundation.org> References: <1185185020.8197.11.camel@twins> <20070723113712.c0ee29e5.akpm@linux-foundation.org> Content-Type: text/plain Date: Mon, 23 Jul 2007 20:40:48 +0200 Message-Id: <1185216048.5535.1.camel@lappy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: Linus Torvalds , linux-kernel , Christoph Lameter , Daniel Phillips , linux-mm List-ID: On Mon, 2007-07-23 at 11:37 -0700, Andrew Morton wrote: > On Mon, 23 Jul 2007 12:03:40 +0200 Peter Zijlstra wrote: > > > Daniel recently spotted that __GFP_ZERO is not (and has never been) > > part of GFP_LEVEL_MASK. I could not find a reason for this in the > > original patch: 3977971c7f09ce08ed1b8d7a67b2098eb732e4cd in the -bk > > tree. > > It doesn't make a lot of sense to be passing __GFP_ZERO into slab > allocation functions. It's not really for the caller to be telling slab > how it should arrange for its new memory to get zeroed. > > And the caller of slab functions will need to zero the memory anyway, > because you don't know whether your new object came direct from the page > allocator or if it is recycled memory from a partial slab. > > I have a feeling that we did support passing __GFP_ZERO into the slab > allocation functions for a while, but took it out. Didn't we just reinstate doing that? /me goes look at .23-rc1 # grep __GFP_ZERO mm/sl[uoa]b.c mm/slab.c: BUG_ON(flags & ~(GFP_DMA | __GFP_ZERO | GFP_LEVEL_MASK)); mm/slab.c: if (unlikely((flags & __GFP_ZERO) && ptr)) mm/slab.c: if (unlikely((flags & __GFP_ZERO) && objp)) mm/slob.c: if (unlikely((gfp & __GFP_ZERO) && b)) mm/slub.c: BUG_ON(flags & ~(GFP_DMA | __GFP_ZERO | GFP_LEVEL_MASK)); mm/slub.c: if (unlikely((gfpflags & __GFP_ZERO) && object)) seems to suggest we do. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org