Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]

[Matt Mackall <mpm@selenic.com>]

On Sat, Dec 08, 2007 at 09:54:06AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> > 
> > But I'll apply it anyway, because it looks "obviously correct" from the 
> > standpoint that the _other_??slob user already clears the end result 
> > explicitly later on, and we simply should never pass down __GFP_ZERO to 
> > the actual page allocator.
> 
> Actually, I take that back. The other slob users are different. They share 
> pages, this codepath does not.
> 
> So I think a more proper solution would be:
>  (a) Something like this patch (which includes my previous mm/slub.c 
>      change)
>  (b) don't warn about atomic GFP_ZERO's - unless they have GFP_HIGHMEM set 
>      *too*.

But what about:

(c) stop passing GFP_ZERO to kmalloc allocators
    stop fiddling with flags inside allocators
    remove ugly if (unlikely(gfp & GFP_ZERO)) from kmalloc allocators
    make kzalloc and kcalloc non-inline functions that do the memset

That should:

- make both kmalloc and kzalloc/kcalloc faster (one less branch)
- reduce kernel size

GFP_ZERO is a bit of an abuse here, given that we don't even intend to
pass it to the underlying "GFP".

-- 
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/