From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754627AbbCXQK6 (ORCPT ); Tue, 24 Mar 2015 12:10:58 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:59753 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753503AbbCXQKx (ORCPT ); Tue, 24 Mar 2015 12:10:53 -0400 Date: Tue, 24 Mar 2015 17:10:37 +0100 From: Peter Zijlstra To: Morten Rasmussen 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: <20150324161037.GY23123@twins.programming.kicks-ass.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150324104423.GC18994@e105550-lin.cambridge.arm.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.