On Tue, 24 Jul 2007 16:58:51 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote:
> 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? I don't see what's special about that dma_alloc_coherent() call. > 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? Fix callers, I'd suggest. There are a number of fishy-looking open-coded usages of __GFP_COMP around the place. It's a bit sad that some architectures are using slab for dma_alloc_coherent() while others go to alloc_pages(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/