[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020803291652l13d3de82o424e126655b86119@mail.gmail.com>
Date: Sun, 30 Mar 2008 01:52:18 +0200
From: "Pekka Enberg" <penberg@...helsinki.fi>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc: "Christoph Lameter" <clameter@....com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"Pawel Staszewski" <pstaszewski@...com.pl>,
LKML <linux-kernel@...r.kernel.org>,
"Adrian Bunk" <bunk@...nel.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Natalie Protasevich" <protasnb@...il.com>
Subject: Re: 2.6.25-rc7-git2: Reported regressions from 2.6.24
Hi,
On Sat, 29 Mar 2008, Christoph Lameter wrote:
> > Yes it uses its own logic if the object is managed by SLUB but not if the
> > object is too big and/or the allocation forwarded to the page allocator
> > or for other internal allocations of buffers etc.
On Sat, Mar 29, 2008 at 11:29 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> Wrong.
>
> It uses it's own logic for __GFP_ZERO *regardless* of size.
Christoph, I think you're overlooking the same thing I was until Linus
straightened me out. We're calling kmalloc_large() from __slab_alloc()
for the fall-back case which causes a bug fixed by Linus' revert.
On Sat, Mar 29, 2008 at 11:29 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> You don't have a f*cking clue about this cocde that you're supposed to be
> maintaining, do you?
Yeah, me too. Fortunately we have you as our upstream maintainer :-).
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists