From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 24 Jul 2007 16:58:51 -0700 (PDT) From: Christoph Lameter Subject: Re: [PATCH] add __GFP_ZERO to GFP_LEVEL_MASK In-Reply-To: <20070724161247.ee1a2546.akpm@linux-foundation.org> Message-ID: References: <1185185020.8197.11.camel@twins> <20070723112143.GB19437@skynet.ie> <1185190711.8197.15.camel@twins> <1185256869.8197.27.camel@twins> <1185261894.8197.33.camel@twins> <20070724120751.401bcbcb@schroedinger.engr.sgi.com> <20070724122542.d4ac734a.akpm@linux-foundation.org> <20070724151046.d8fbb7da.akpm@linux-foundation.org> <20070724161247.ee1a2546.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: Peter Zijlstra , Mel Gorman , Linus Torvalds , linux-kernel , Daniel Phillips , linux-mm List-ID: On Tue, 24 Jul 2007, Andrew Morton wrote: > __GFP_COMP I'm not so sure about. > drivers/char/drm/drm_pci.c:drm_pci_alloc() (and other places like infiniband) > pass it into dma_alloc_coherent() which some architectures implement via slab. umm, > arch/arm/mm/consistent.c is one such. Should drm_pci_alloc really aright in setting __GFP_COMP? dma_alloc_coherent does not set __GFP_COMP for other higher order allocs and expects to be able to operate on the page structs indepedently. That is not the case for a compound page. Creates a really interesting case for SLAB. Slab did not use __GFP_COMP in order to be able to allow the use page->private (No longer an issue since the 2.6.22 cleanups and avoiding the use of page->private for the compound head). Now the __GFP_COMP flag is passed through for any higher order page alloc (such as a kmalloc allocation > PAGE_SIZE). Then we may have allocated one slab that is a compound page amoung others higher order pages allocated without __GFP_COMP. May have caused rare and strange failures in 2.6.21 and earlier because of the concurrent page->private use in compound head pages and arch pages. SLUB will always use __GFP_COMP so the pages are consistent regardless if __GFP_COMP is passed in or not. The strange scenarios come about by expecting a page allocation when sometimes we just substitute a slab alloc. We could filter __GFP_COMP out to avoid the BUG()? Or deal with it on a case by case basis? -- 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