[lkml]   [2007]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] add __GFP_ZERO to GFP_LEVEL_MASK
    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

    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 from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-07-25 02:01    [W:0.034 / U:6.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site