From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756583AbbCXRj1 (ORCPT ); Tue, 24 Mar 2015 13:39:27 -0400 Received: from foss.arm.com ([217.140.101.70]:49009 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755039AbbCXRjX (ORCPT ); Tue, 24 Mar 2015 13:39:23 -0400 Date: Tue, 24 Mar 2015 17:39:55 +0000 From: Morten Rasmussen To: Peter Zijlstra Cc: Dietmar Eggemann , Sai Gurrappadi , "mingo@redhat.com" , "vincent.guittot@linaro.org" , "yuyang.du@intel.com" , "preeti@linux.vnet.ibm.com" , "mturquette@linaro.org" , "nico@linaro.org" , "rjw@rjwysocki.net" , Juri Lelli , "linux-kernel@vger.kernel.org" , Peter Boonstoppel Subject: Re: [RFCv3 PATCH 30/48] sched: Calculate energy consumption of sched_group Message-ID: <20150324173955.GI18994@e105550-lin.cambridge.arm.com> References: <1423074685-6336-1-git-send-email-morten.rasmussen@arm.com> <1423074685-6336-31-git-send-email-morten.rasmussen@arm.com> <55036AA1.7000801@nvidia.com> <20150316141546.GQ4081@e105550-lin.cambridge.arm.com> <20150323164702.GL23123@twins.programming.kicks-ass.net> <551075D9.2040409@arm.com> <20150324104423.GC18994@e105550-lin.cambridge.arm.com> <20150324161037.GY23123@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150324161037.GY23123@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 Tue, Mar 24, 2015 at 04:10:37PM +0000, Peter Zijlstra wrote: > On Tue, Mar 24, 2015 at 10:44:24AM +0000, Morten Rasmussen wrote: > > > > Maybe remind us why this needs to be tied to sched_groups ? Why can't we > > > > attach the energy information to the domains? > > > In the current domain hierarchy you don't have domains with just one cpu > > in them. If you attach the per-cpu energy data to the MC level domain > > which spans the whole cluster, you break the current idea of attaching > > information to the cpumask (currently sched_group, but could be > > sched_domain as we discuss here) the information is associated with. You > > would have to either introduce a level of single cpu domains at the > > lowest level or move away from the idea of attaching data to the cpumask > > that is associated with it. > > > > Using sched_groups we do already have single cpu groups that we can > > attach per-cpu data to, but we are missing a top level group spanning > > the entire system for system wide energy data. So from that point of > > view groups and domains are equally bad. > > Oh urgh, good point that. Cursed if you do, cursed if you don't. Bugger. Yeah :( I don't really care which one we choose. Adding another top level domain with one big group spanning all cpus, but with all SD flags disabled seems less intrusive than adding a level at the bottom. Better ideas are very welcome.