From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932281Ab3A1Lci (ORCPT ); Mon, 28 Jan 2013 06:32:38 -0500 Received: from mout.gmx.net ([212.227.15.18]:65046 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932240Ab3A1Lcd (ORCPT ); Mon, 28 Jan 2013 06:32:33 -0500 X-Authenticated: #14349625 X-Provags-ID: V01U2FsdGVkX1/wsYpNhZbwYdaybO6mF4SgimKdLzdi+Fh9WhwCVS wpIoaNsBvllRsQ Message-ID: <1359372743.5783.136.camel@marge.simpson.net> Subject: Re: [patch v4 0/18] sched: simplified fork, release load avg and power awareness scheduling From: Mike Galbraith To: Borislav Petkov Cc: Alex Shi , torvalds@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, tglx@linutronix.de, akpm@linux-foundation.org, arjan@linux.intel.com, pjt@google.com, namhyung@kernel.org, vincent.guittot@linaro.org, gregkh@linuxfoundation.org, preeti@linux.vnet.ibm.com, viresh.kumar@linaro.org, linux-kernel@vger.kernel.org Date: Mon, 28 Jan 2013 12:32:23 +0100 In-Reply-To: <20130128112922.GA29384@pd.tnic> References: <20130124094439.GB13463@pd.tnic> <51014E34.60309@intel.com> <510493E4.8060602@intel.com> <1359261385.5803.46.camel@marge.simpson.net> <20130127103508.GB8894@pd.tnic> <51052ACB.3070703@intel.com> <1359301903.5805.11.camel@marge.simpson.net> <1359350266.5783.39.camel@marge.simpson.net> <20130128095501.GB6109@pd.tnic> <1359369884.5783.117.camel@marge.simpson.net> <20130128112922.GA29384@pd.tnic> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Y-GMX-Trusted: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2013-01-28 at 12:29 +0100, Borislav Petkov wrote: > On Mon, Jan 28, 2013 at 11:44:44AM +0100, Mike Galbraith wrote: > > On Mon, 2013-01-28 at 10:55 +0100, Borislav Petkov wrote: > > > On Mon, Jan 28, 2013 at 06:17:46AM +0100, Mike Galbraith wrote: > > > > Zzzt. Wish I could turn turbo thingy off. > > > > > > Try setting /sys/devices/system/cpu/cpufreq/boost to 0. > > > > How convenient (test) works too. > > > > So much for turbo boost theory. Nothing changed until I turned load > > balancing off at NODE. High end went to hell (gee), but low end... > > > > Benchmark Version Machine Run Date > > AIM Multiuser Benchmark - Suite VII "1.1" performance-no-node-load_balance Jan 28 11:20:12 2013 > > > > Tasks Jobs/Min JTI Real CPU Jobs/sec/task > > 1 436.3 100 13.9 3.9 7.2714 > > 5 2637.1 99 11.5 7.3 8.7903 > > 10 5415.5 99 11.2 11.3 9.0259 > > 20 10603.7 99 11.4 24.8 8.8364 > > 40 20066.2 99 12.1 40.5 8.3609 > > 80 35079.6 99 13.8 75.5 7.3082 > > 160 55884.7 98 17.3 145.6 5.8213 > > 320 79345.3 98 24.4 287.4 4.1326 > > If you're talking about those results from earlier: > > Benchmark Version Machine Run Date > AIM Multiuser Benchmark - Suite VII "1.1" performance Jan 28 08:09:20 2013 > > Tasks Jobs/Min JTI Real CPU Jobs/sec/task > 1 438.8 100 13.8 3.8 7.3135 > 5 2634.8 99 11.5 7.2 8.7826 > 10 5396.3 99 11.2 11.4 8.9938 > 20 10725.7 99 11.3 24.0 8.9381 > 40 20183.2 99 12.0 38.5 8.4097 > 80 35620.9 99 13.6 71.4 7.4210 > 160 57203.5 98 16.9 137.8 5.9587 > 320 81995.8 98 23.7 271.3 4.2706 > > then the above no_node-load_balance thing suffers a small-ish dip at 320 > tasks, yeah. No no, that's not restricted to one node. It's just overloaded because I turned balancing off at the NODE domain level. > And AFAICR, the effect of disabling boosting will be visible in the > small count tasks cases anyway because if you saturate the cores with > tasks, the boosting algorithms tend to get the box out of boosting for > the simple reason that the power/perf headroom simply disappears due to > the SOC being busy. > > > 640 100294.8 98 38.7 570.9 2.6118 > > 1280 115998.2 97 66.9 1132.8 1.5104 > > 2560 125820.0 97 123.3 2256.6 0.8191 > > I dunno about those. maybe this is expected with so many tasks or do we > want to optimize that case further? When using all 4 nodes properly, that's still scaling. Here, I intentionally screwed up balancing to watch the low end. High end is expected wreckage. -Mike