Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751950AbbHLSr7 (ORCPT ); Wed, 12 Aug 2015 14:47:59 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:23074 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbbHLSr5 convert rfc822-to-8bit (ORCPT ); Wed, 12 Aug 2015 14:47:57 -0400 Message-ID: <55CB94D9.9000107@arm.com> Date: Wed, 12 Aug 2015 19:47:53 +0100 From: Dietmar Eggemann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Peter Zijlstra , Morten Rasmussen CC: "mingo@redhat.com" , "vincent.guittot@linaro.org" , "daniel.lezcano@linaro.org" , "yuyang.du@intel.com" , "mturquette@baylibre.com" , "rjw@rjwysocki.net" , Juri Lelli , "sgurrappadi@nvidia.com" , "pang.xunlei@zte.com.cn" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , Russell King Subject: Re: [RFCv5 PATCH 18/46] arm: topology: Define TC2 energy and provide it to the scheduler References: <1436293469-25707-1-git-send-email-morten.rasmussen@arm.com> <1436293469-25707-19-git-send-email-morten.rasmussen@arm.com> <20150812103320.GW19282@twins.programming.kicks-ass.net> In-Reply-To: <20150812103320.GW19282@twins.programming.kicks-ass.net> X-OriginalArrivalTime: 12 Aug 2015 18:47:54.0865 (UTC) FILETIME=[6634A610:01D0D52F] X-MC-Unique: VevtLVHrQKKg7JM1rOqdKA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1957 Lines: 47 On 12/08/15 11:33, Peter Zijlstra wrote: > On Tue, Jul 07, 2015 at 07:24:01PM +0100, Morten Rasmussen wrote: >> +static struct capacity_state cap_states_cluster_a7[] = { >> + /* Cluster only power */ >> + { .cap = 150, .power = 2967, }, /* 350 MHz */ >> + { .cap = 172, .power = 2792, }, /* 400 MHz */ >> + { .cap = 215, .power = 2810, }, /* 500 MHz */ >> + { .cap = 258, .power = 2815, }, /* 600 MHz */ >> + { .cap = 301, .power = 2919, }, /* 700 MHz */ >> + { .cap = 344, .power = 2847, }, /* 800 MHz */ >> + { .cap = 387, .power = 3917, }, /* 900 MHz */ >> + { .cap = 430, .power = 4905, }, /* 1000 MHz */ >> + }; > > So can I suggest a SCHED_DEBUG validation of the data provided? Yes we can do that. > > Given the above table, it _never_ makes sense to run at .cap=150, it > equally also doesn't make sense to run at .cap = 301. > Absolutely right. > So please add a SCHED_DEBUG test on domain creation that validates that > not only is the .cap monotonically increasing, but the .power is too. The requirement for current EAS code to work is even higher. We're not only requiring monotonically increasing values for .cap and .power but that the energy efficiency (.cap/.power) is monotonically decreasing. Otherwise we can't stop the search for a new appropriate OPP in find_new_capacity() in case .cap >= current 'max. group usage' because we can't assume that this OPP will be the most energy efficient one. For the example above we get .cap/.power = [0.05 0.06 0.08 0.09 0.1 0.12 0.1 0.09] so only the last 3 OPPs [800, 900, 1000 Mhz] make sense from this perspective on our TC2 test chip platform. So we should check for monotonically decreasing (.cap/.power) values. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/