From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756784AbaAHNpV (ORCPT ); Wed, 8 Jan 2014 08:45:21 -0500 Received: from fw-tnat.austin.arm.com ([217.140.110.23]:42091 "EHLO collaborate-mta1.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752039AbaAHNpQ (ORCPT ); Wed, 8 Jan 2014 08:45:16 -0500 Date: Wed, 8 Jan 2014 13:45:16 +0000 From: Morten Rasmussen To: Peter Zijlstra Cc: Vincent Guittot , Dietmar Eggemann , "linux-kernel@vger.kernel.org" , "mingo@kernel.org" , "pjt@google.com" , "cmetcalf@tilera.com" , "tony.luck@intel.com" , "alex.shi@linaro.org" , "preeti@linux.vnet.ibm.com" , "linaro-kernel@lists.linaro.org" , "paulmck@linux.vnet.ibm.com" , "corbet@lwn.net" , "tglx@linutronix.de" , "len.brown@intel.com" , "arjan@linux.intel.com" , "amit.kucheria@linaro.org" , "james.hogan@imgtec.com" , "schwidefsky@de.ibm.com" , "heiko.carstens@de.ibm.com" Subject: Re: [RFC] sched: CPU topology try Message-ID: <20140108134516.GM2936@e103034-lin> References: <20140106163123.GN31570@twins.programming.kicks-ass.net> <20140107132220.GZ31570@twins.programming.kicks-ass.net> <20140107141059.GY3694@twins.programming.kicks-ass.net> <20140107154154.GH2936@e103034-lin> <20140107204951.GD2480@laptop.programming.kicks-ass.net> <20140108123534.GI2936@e103034-lin> <20140108124534.GD31570@twins.programming.kicks-ass.net> <20140108132739.GK2936@e103034-lin> <20140108133257.GF31570@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140108133257.GF31570@twins.programming.kicks-ass.net> 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 Wed, Jan 08, 2014 at 01:32:57PM +0000, Peter Zijlstra wrote: > On Wed, Jan 08, 2014 at 01:27:39PM +0000, Morten Rasmussen wrote: > > On Wed, Jan 08, 2014 at 12:45:34PM +0000, Peter Zijlstra wrote: > > > On Wed, Jan 08, 2014 at 12:35:34PM +0000, Morten Rasmussen wrote: > > > > > Currently we detect overload by sg.nr_running >= sg.capacity, which can > > > > > be very misleading because while a cpu might have a task running 'now' > > > > > it might be 99% idle. > > > > > > > > > > At which point I argued we should change the capacity thing anyhow. Ever > > > > > since the runnable_avg patch set I've been arguing to change that into > > > > > an actual utilization test. > > > > > > > > > > So I think that if we measure overload by something like >95% utilization > > > > > on the entire group the load scaling again makes perfect sense. > > > > > > > > I agree that it make more sense to change the overload test to be based > > > > on some tracked load. How about the non-overloaded case? Load balancing > > > > would have to be based on unweighted task loads in that case? > > > > > > Yeah, until we're overloaded our goal is to minimize idle time. > > > > I would say, make the most of the available cpu cycles. Minimizing idle > > time is not always the right thing to do when considering power > > awareness. > > > > If we know the actual load of the tasks, we may be able to consolidate > > I think we must start to be careful with the word load, I think you > meant to say utilization. Indeed, I meant utilization. > > > them on fewer cpus and save power by idling cpus. In that case the idle > > time (total) is unchanged (unless the P-state is changed). Somewhat > > similar to the video use-case running on 1, 2, and 4 cpu that I reposted > > yesterday. > > But fair enough.. Its idle time when you consider CPUs to always run at > max frequency, but clearly I must stop thinking about CPUs like that :-) Yes, it opens a whole new world of problems to be solved :-)