Date: Wed, 25 May 2011 10:04:05 -0500 (CDT)
From: Christoph Lameter <cl@linux.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
cc: James Morris <jmorris@namei.org>, Pekka Enberg <penberg@kernel.org>,
        linux-kernel@vger.kernel.org
Subject: Re: SLUB regression in current Linus
In-Reply-To: <BANLkTiksf8NJ40twt1nxp6oRAqNv45QeCQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1105251003150.23309@router.home>
References: <alpine.LRH.2.00.1105242146240.12134@tundra.namei.org> <alpine.LRH.2.00.1105242204100.12283@tundra.namei.org> <alpine.DEB.2.00.1105240908100.25760@router.home> <alpine.LRH.2.00.1105250813290.16922@tundra.namei.org> <alpine.DEB.2.00.1105250945240.23309@router.home>
 <BANLkTiksf8NJ40twt1nxp6oRAqNv45QeCQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 868
Lines: 23

On Wed, 25 May 2011, Linus Torvalds wrote:

> On Wed, May 25, 2011 at 7:47 AM, Christoph Lameter <cl@linux.com> wrote:
> >
> > So simply return the object. In the debug case we do not need all the other
> > processing that unlock_out: does.
>
> So that patch looks like it should explain things.
>
> But exactly why don't we need the ->tid update and the ALLOC_SLOWPATH
> stats? Both of them would seem to be equally valid for the debug case.

We always fall back to the slow path in the debug case. So the tid update
is useless.

ALLOC_SLOWPATH would just be incremented for all allocations. Also a
pretty useless thing.

--
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/