From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753738Ab2LKPWO (ORCPT ); Tue, 11 Dec 2012 10:22:14 -0500 Received: from cantor2.suse.de ([195.135.220.15]:49842 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753030Ab2LKPWN (ORCPT ); Tue, 11 Dec 2012 10:22:13 -0500 Date: Tue, 11 Dec 2012 15:22:07 +0000 From: Mel Gorman To: Ingo Molnar Cc: Peter Zijlstra , Andrea Arcangeli , Rik van Riel , Johannes Weiner , Hugh Dickins , Thomas Gleixner , Paul Turner , Hillf Danton , David Rientjes , Lee Schermerhorn , Alex Shi , Srikar Dronamraju , Aneesh Kumar , Linus Torvalds , Andrew Morton , Linux-MM , LKML Subject: Re: [PATCH 00/49] Automatic NUMA Balancing v10 Message-ID: <20121211152207.GQ1009@suse.de> References: <1354875832-9700-1-git-send-email-mgorman@suse.de> <20121207110113.GB21482@gmail.com> <20121209203630.GC1009@suse.de> <20121210113945.GA7550@gmail.com> <20121210152405.GJ1009@suse.de> <20121211010201.GP1009@suse.de> <20121211085238.GA21673@gmail.com> <20121211091807.GA23600@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20121211091807.GA23600@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 11, 2012 at 10:18:07AM +0100, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > > This is prototype only but what I was using as a reference > > > to see could I spot a problem in yours. It has not been even > > > boot tested but avoids remote->remote copies, contending on > > > PTL or holding it longer than necessary (should anyway) > > > > So ... because time is running out and it would be nice to > > progress with this for v3.8, I'd suggest the following > > approach: > > > > - Please send your current tree to Linus as-is. You already > > have my Acked-by/Reviewed-by for its scheduler bits, and my > > testing found your tree to have no regression to mainline, > > plus it's a nice win in a number of NUMA-intense workloads. > > So it's a good, monotonic step forward in terms of NUMA > > balancing, very close to what the bits I'm working on need as > > infrastructure. > > > > - I'll rebase all my devel bits on top of it. Instead of > > removing the migration bandwidth I'll simply increase it for > > testing - this should trigger similarly aggressive behavior. > > I'll try to touch as little of the mm/ code as possible, to > > keep things debuggable. > > One minor last-minute request/nit before you send it to Linus, > would you mind doing a: > > CONFIG_BALANCE_NUMA => CONFIG_NUMA_BALANCING > > rename please? (I can do it for you if you don't have the time.) > > CONFIG_NUMA_BALANCING is really what fits into our existing NUMA > namespace, CONFIG_NUMA, CONFIG_NUMA_EMU - and, more importantly, > the ordering of words follows the common generic -> less generic > ordering we do in the kernel for config names and methods. > > So it would fit nicely into existing Kconfig naming schemes: > > CONFIG_TRACING > CONFIG_FILE_LOCKING > CONFIG_EVENT_TRACING > > etc. > Yes, that makes sense. I should have spotted the rationale. I also took the liberty of renaming the command-line parameter and the variables to be consistent with this. -- Mel Gorman SUSE Labs