From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756593Ab2LNQFS (ORCPT ); Fri, 14 Dec 2012 11:05:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57891 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756252Ab2LNQFQ (ORCPT ); Fri, 14 Dec 2012 11:05:16 -0500 From: Jeff Moyer To: James Bottomley Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, Bart Van Assche Subject: Re: [patch,v3,repost 00/10] make I/O path allocations more numa-friendly References: <1354034799-8460-1-git-send-email-jmoyer@redhat.com> <1355220811.2400.5.camel@dabdike.int.hansenpartnership.com> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Fri, 14 Dec 2012 11:05:04 -0500 In-Reply-To: <1355220811.2400.5.camel@dabdike.int.hansenpartnership.com> (James Bottomley's message of "Tue, 11 Dec 2012 10:13:31 +0000") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) 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 James Bottomley writes: > On Mon, 2012-12-10 at 12:59 -0500, Jeff Moyer wrote: >> Jeff Moyer writes: >> >> > Hi, >> > >> > This patch set makes memory allocations for data structures used in >> > the I/O path more numa friendly by allocating them from the same numa >> > node as the storage device. I've only converted a handful of drivers >> > at this point. My testing is limited by the hardware I have on hand. >> > Using these patches, I was able to max out the bandwidth of the storage >> > controller when issuing I/O from any node on my 4 node system. Without >> > the patch, I/O from nodes remote to the storage device would suffer a >> > penalty ranging from 6-12%. Given my relatively low-end setup[1], I >> > wouldn't be surprised if others could show a more significant performance >> > advantage. >> > >> > This is a repost of the last posting. The only changes are additional >> > reviewed-by/acked-by tags. I think this version is ready for inclusion. >> > James, would you mind taking a look? >> >> James? Do you have any objections to including this for 3.8? > > Probably for 3.9 since the 3.8 merge window is upon us. OK. > Do we actually have any performance numbers from the big system people? > That's really a must for this type of work. I'm working on getting some numbers. > It's missing acks from the affected drivers; that's not a show stopper > but it would be better to have them. Well, we could trim the driver list to those that have ACKs, but the driver changes are trivial. Thanks, Jeff