From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753868AbbEAPJb (ORCPT ); Fri, 1 May 2015 11:09:31 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:45124 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbbEAPJ2 convert rfc822-to-8bit (ORCPT ); Fri, 1 May 2015 11:09:28 -0400 Message-ID: <55439728.2040307@arm.com> Date: Fri, 01 May 2015 16:09:28 +0100 From: Dietmar Eggemann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "pang.xunlei@zte.com.cn" CC: Juri Lelli , "linux-kernel@vger.kernel.org" , "linux-kernel-owner@vger.kernel.org" , "mingo@redhat.com" , Morten Rasmussen , "mturquette@linaro.org" , "nico@linaro.org" , "peterz@infradead.org" , "preeti@linux.vnet.ibm.com" , "rjw@rjwysocki.net" , "vincent.guittot@linaro.org" , "yuyang.du@intel.com" Subject: Re: [RFCv3 PATCH 37/48] sched: Determine the current sched_group idle-state References: <1423074685-6336-1-git-send-email-morten.rasmussen@arm.com> <1423074685-6336-38-git-send-email-morten.rasmussen@arm.com> <55428DEF.7080801@arm.com> In-Reply-To: X-OriginalArrivalTime: 01 May 2015 15:09:24.0778 (UTC) FILETIME=[CF6FE0A0:01D08420] X-MC-Unique: nl_fWOmrS-yzWcZB5TQLXw-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 On 01/05/15 10:56, pang.xunlei@zte.com.cn wrote: > Hi Dietmar, > > Dietmar Eggemann wrote 2015-05-01 AM 04:17:51: >> >> Re: [RFCv3 PATCH 37/48] sched: Determine the current sched_group > idle-state >> >> On 30/04/15 06:12, pang.xunlei@zte.com.cn wrote: >> > linux-kernel-owner@vger.kernel.org wrote 2015-02-05 AM 02:31:14: [...] > Thanks for explaining this in graphic detail. > > From what I understood, let's just assume ARM TC2 has an extra > MC-level C-States SPC(assuming its power is 40 for the big). > > Take the power value from "RFCv3 PATCH 25/48": > static struct idle_state idle_states_cluster_a15[] = { > { .power = 70 }, /* WFI */ > { .power = 25 }, /* cluster-sleep-b */ > }; > > static struct idle_state idle_states_core_a15[] = { > { .power = 0 }, /* WFI */ > }; > > Then we will get the following idle energy table? > static struct idle_state idle_states_core_a15[] = { > { .power = 70 }, /* WFI */ > { .power = 0 }, /* SPC*/ > }; > > static struct idle_state idle_states_cluster_a15[] = { > { .power = 40 }, /* SPC */ > { .power = 25 }, /* cluster-sleep-b */ > }; > > Is this correct? Yes. It's the same C-state configuration we have on our ARMv8 big.LITTLE JUNO (Cortex A57, A53) board. # cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name WFI cpu-sleep-0 cluster-sleep-0 > If this is right, there may be a bug. > > For MC-level CPU0: > sg_mask=0x1 sge->nr_idle_states=2 sge->idle_states_below=0 > cpuidle_idx=0 group_idx=1 shallowest_state=1 > > See, group_idle_state() finally returns 1 as CPU0's MC-level > idle engery model index, and this is obviously wrong. Yes, I can see this problem too. > So, I think for > "int group_idx = cpuidle_idx - sge->idle_states_below + 1;" > > Maybe we shouldn't add the extra 1 for lowest levels? Maybe. In any case we will have to resolve this issue in the next version. Thanks for pointing this out! [...]