lkml.org 
[lkml]   [2008]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.25-rc7-git2: Reported regressions from 2.6.24
    On Thu, 27 Mar 2008, Linus Torvalds wrote:

    > Totally irrelevant.
    >
    > The page allocation path does
    >
    > if (gfp_flags & __GFP_ZERO)
    > prep_zero_page(page, order, gfp_flags);
    >
    > and that will cause a warning REGARDLESS of whether the page is a HIGHMEM
    > page or not.


    prep_zero_page does:

    static inline void prep_zero_page(struct page *page, int order, gfp_t
    gfp_flags)
    {
    int i;

    /*
    * clear_highpage() will use KM_USER0, so it's a bug to use __GFP_ZERO
    * and __GFP_HIGHMEM from hard or soft interrupt context.
    */
    VM_BUG_ON((gfp_flags & __GFP_HIGHMEM) && in_interrupt());
    for (i = 0; i < (1 << order); i++)
    clear_highpage(page + i);
    }

    So we forbit __GFP_HIGHMEM and in_interrupt which makes sense. The simple
    forwarding of large kmallocs to the page allocator as done by SLUB / SLOB
    is fine.

    Then clear_highpage calls additional checking functions that have
    the effect of generally forbiding zeroing in interrupt context if
    CONFIG_HIGHMEM is set. This is wrong and needs to be fixed.

    > And the fact is, passing in GFP_ZERO from the SLUB code is a bug
    > regardless, because it unnecessarily does the dual memset().

    Well that is only the fallback path of __slab_alloc which is not triggered
    here and not performance sensitive. We could clear the flag there but
    that is irrevelant for this issue.


    \
     
     \ /
      Last update: 2008-03-28 19:39    [W:0.024 / U:0.460 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site