From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764939AbXKOBrs (ORCPT ); Wed, 14 Nov 2007 20:47:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753734AbXKOBrk (ORCPT ); Wed, 14 Nov 2007 20:47:40 -0500 Received: from smtp107.mail.mud.yahoo.com ([209.191.85.217]:43681 "HELO smtp107.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751322AbXKOBrj (ORCPT ); Wed, 14 Nov 2007 20:47:39 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=k8a90RErpUZ0ztwGj6vtUm1q11mtoiZqKdijeDmGYw6IQZ4t0oYHcuWyvjXJoUkATw9bipbRnxIGR07p/kpAn9Pmr7EAvm7/3s69WG3ESHiT85gCZnU4AJJ5lcgL9SYmBLvOr9bocQ2ymVsp6LWkNvy4dKNOgSF2/Ye4jlWd2hg= ; X-YMail-OSG: wf5Qs6YVM1lPRdJzSKmn0VJk50sIlzO2rm5lFqbnZusXNS1jA1RpHtuIwlNmYBCGBEkySY2NSQ-- From: Nick Piggin To: Herbert Xu Subject: Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench Date: Thu, 15 Nov 2007 12:47:29 +1100 User-Agent: KMail/1.9.5 Cc: Christoph Lameter , David Miller , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <200711140927.39796.nickpiggin@yahoo.com.au> <20071115011110.GB21193@gondor.apana.org.au> In-Reply-To: <20071115011110.GB21193@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711151247.29424.nickpiggin@yahoo.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 15 November 2007 12:11, Herbert Xu wrote: > On Wed, Nov 14, 2007 at 05:03:25PM -0800, Christoph Lameter wrote: > > Well this is likely the result of the SLUB regression. If you allocate an > > order 1 page then the zone locks need to be taken. SLAB queues the a Yeah, it appears this is what happened. The lockless page allocator fastpath appears on the list and the slowpaths disappear after Herbert's patches. SLAB is doing its own thing, so it avoids that pitfall. > > couple of higher order pages and can so serve a couple of requests > > without going into the page allocator whereas SLUB has to go directly to > > the page allocator for allocate and free. I guess that needs fixing in > > the page allocator. Or do I need to add a mechanism to buffer higher > > order page allcoations to SLUB? > > Actually this serves to discourage people from using high-order > allocations which IMHO is a good thing :) Yeah I completely agree. The right fix is in the caller... The bug / suboptimal allocation would not have been found in tcp if not for this ;)