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
2007-12-08T18:34:37Z

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.