From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932095AbZHKPU4 (ORCPT ); Tue, 11 Aug 2009 11:20:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752341AbZHKPUz (ORCPT ); Tue, 11 Aug 2009 11:20:55 -0400 Received: from one.firstfloor.org ([213.235.205.2]:34982 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751012AbZHKPUz (ORCPT ); Tue, 11 Aug 2009 11:20:55 -0400 To: Prarit Bhargava Cc: balbir@linux.vnet.ibm.com, Andrew Morton , KAMEZAWA Hiroyuki , "nishimura@mxp.nes.nec.co.jp" , KOSAKI Motohiro , "menage@google.com" , andi.kleen@intel.com, Pavel Emelianov , "lizf@cn.fujitsu.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: Help Resource Counters Scale better (v4) From: Andi Kleen References: <20090811144405.GW7176@balbir.in.ibm.com> <4A81863A.2050504@redhat.com> Date: Tue, 11 Aug 2009 17:20:54 +0200 In-Reply-To: <4A81863A.2050504@redhat.com> (Prarit Bhargava's message of "Tue, 11 Aug 2009 10:54:50 -0400") Message-ID: <87d472gyw9.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (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 Prarit Bhargava writes: > > On a 64p/32G system running 2.6.31-git2-rc5, with RESOURCE_COUNTERS This is CONFIG_RESOURCE_COUNTERS off at compile time right? > off, "time make -j64" results in > > real 4m54.972s > user 90m13.456s > sys 50m19.711s > > On the same system, running 2.6.31-git2-rc5, with RESOURCE_COUNTERS on, > plus Balbir's "Help Resource Counters Scale Better (v3)" patch, and > this patch, results in > > real 4m18.607s > user 84m58.943s > sys 50m52.682s Hmm, so resource counters on with the patch is faster than CONFIG_RESOURCE_COUNTERS compiled out in real time? That seems counterintuitive. At best I would expect the patch to break even, but not be actually faster. Is the compilation stable over multiple runs? Still it looks like the patch is clearly needed. -Andi -- ak@linux.intel.com -- Speaking for myself only.