Messages in this thread | | | Date | Fri, 28 Mar 2008 11:33:05 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: 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.
| |