Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261659AbVBHU2Q (ORCPT ); Tue, 8 Feb 2005 15:28:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261657AbVBHU2Q (ORCPT ); Tue, 8 Feb 2005 15:28:16 -0500 Received: from fw.osdl.org ([65.172.181.6]:24980 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S261653AbVBHU2J (ORCPT ); Tue, 8 Feb 2005 15:28:09 -0500 Date: Tue, 8 Feb 2005 12:27:58 -0800 From: Andrew Morton To: Christoph Lameter Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org Subject: Re: prezeroing V6 [2/3]: ScrubD Message-Id: <20050208122758.5c669281.akpm@osdl.org> In-Reply-To: References: <1106828124.19262.45.camel@hades.cambridge.redhat.com> <20050202153256.GA19615@logos.cnet> <20050207163035.7596e4dd.akpm@osdl.org> <20050207170947.239f8696.akpm@osdl.org> <20050207173559.68ce30e3.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1947 Lines: 42 Christoph Lameter wrote: > > On Mon, 7 Feb 2005, Andrew Morton wrote: > > > > No its a page fault benchmark. Dave Miller has done some kernel compiles > > > and I have some benchmarks here that I never posted because they do not > > > show any material change as far as I can see. I will be posting that soon > > > when this is complete (also need to do the same for the atomic page fault > > > ops and the prefaulting patch). > > > > OK, thanks. That's important work. After all, this patch is a performance > > optimisation. > > Well its a bit complicated due to the various configuration. UP, and then > more and more processors. Plus the NUMA stuff and the standard benchmarks > that are basically not suited for SMP tests make this a bit difficult. The patch is supposed to speed the kernel up with at least some workloads. We 100% need to see testing results with some such workloads to verify that the patch is desirable. We also need to try to identify workloads whcih might experience a regression and test them too. It isn't very hard. > > > memory node is bound to a set of cpus. This may be controlled by the > > > NUMA node configuration. F.e. for nodes without cpus. > > > > kthread_bind() should be able to do this. From a quick read it appears to > > have shortcomings in this department (it expects to be bound to a single > > CPU). > > Sorry but I still do not get what the problem is? kscrubd does exactly > what kswapd does and can be handled in the same way. It works fine here > on various multi node configurations and correctly gets CPUs assigned. We now have a standard API for starting, binding and stopping kernel threads. It's best to use it. - 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/