From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753755AbYENVdd (ORCPT ); Wed, 14 May 2008 17:33:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755555AbYENVdP (ORCPT ); Wed, 14 May 2008 17:33:15 -0400 Received: from relay1.sgi.com ([192.48.171.29]:34160 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755313AbYENVdN (ORCPT ); Wed, 14 May 2008 17:33:13 -0400 Date: Wed, 14 May 2008 14:33:11 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Matthew Wilcox cc: Andi Kleen , Pekka Enberg , KOSAKI Motohiro , Rik van Riel , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Mel Gorman , mpm@selenic.com, "Zhang, Yanmin" Subject: Re: [patch 21/21] slab defrag: Obsolete SLAB In-Reply-To: <20080514212130.GD9921@parisc-linux.org> Message-ID: References: <4825709A.2020407@firstfloor.org> <20080510221515.3540a6cc@bree.surriel.com> <2f11576a0805120038s334dc56cuaf16b8b7c6f87098@mail.gmail.com> <84144f020805120054t1370236ei5ff52279457e026e@mail.gmail.com> <482B2617.5010605@firstfloor.org> <20080514205842.GC9921@parisc-linux.org> <20080514212130.GD9921@parisc-linux.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 May 2008, Matthew Wilcox wrote: > > No. I thought you were satisfied with the performance increase you saw > > when pinning the process to a single processor? > > Er, no. That program emulates a TPC-C run from the point of view of > doing as much IO as possible from all CPUs. Pinning the process to one > CPU would miss the point somewhat. Oh. The last message I got was an enthusiatic report on the performance gains you saw by pinning the process after we looked at slub statistics that showed that the behavior of the tests was different from your expectations. I got messages here that indicate that this was a scsi testing program that you had under development. And yes we saw the remote freeing degradations there. > I seem to remember telling you that you might get more realistic > performance numbers by pinning the scsi_ram_0 kernel thread to a single > CPU (ie emulating an interrupt tied to one CPU rather than letting the > scheduler choose to run the thread on the 'best' CPU). If this is a stand in for the TPC then why did you not point that out when Pekka and I recently asked you to retest some configurations?