From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751490AbcGNPNp (ORCPT ); Thu, 14 Jul 2016 11:13:45 -0400 Received: from foss.arm.com ([217.140.101.70]:43575 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751051AbcGNPNo (ORCPT ); Thu, 14 Jul 2016 11:13:44 -0400 Date: Thu, 14 Jul 2016 16:15:20 +0100 From: Morten Rasmussen To: Vincent Guittot Cc: Dietmar Eggemann , Peter Zijlstra , "mingo@redhat.com" , Yuyang Du , mgalbraith@suse.de, linux-kernel Subject: Re: [PATCH v2 06/13] sched: Store maximum per-cpu capacity in root domain Message-ID: <20160714151518.GD21816@e105550-lin.cambridge.arm.com> References: <1466615004-3503-1-git-send-email-morten.rasmussen@arm.com> <1466615004-3503-7-git-send-email-morten.rasmussen@arm.com> <578646A8.1070607@arm.com> <20160713163723.GC21816@e105550-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu, Jul 14, 2016 at 03:25:36PM +0200, Vincent Guittot wrote: > On 13 July 2016 at 18:37, Morten Rasmussen wrote: > > On Wed, Jul 13, 2016 at 02:48:24PM +0100, Dietmar Eggemann wrote: > >> On 13/07/16 13:40, Vincent Guittot wrote: > >> > On 22 June 2016 at 19:03, Morten Rasmussen wrote: > >> >> From: Dietmar Eggemann > >> >> > >> >> To be able to compare the capacity of the target cpu with the highest > >> >> available cpu capacity, store the maximum per-cpu capacity in the root > >> >> domain. > >> > > >> > I thought that the capacity of all CPUS were built so the highest > >> > capacity of the CPU of the system is 1024 for big LITTLE system . So > >> > this patch doesn't seem necessary for big.LITTLE system > >> > >> The asymmetric cpu capacity support currently only has an effect on arm > >> big.LITTLE (32bit) using the existing 'struct cpu_efficiency > >> table_efficiency[]' based approach. > > > > True for this patch set, but longer term and if you use the preview > > branch mentioned in the cover letter Vincent is right. The idea is that > > the highest capacity anywhere should be 1024. > > > > If we fix the arch/arm/kernel/topology.c code at the same time we could > > kill this patch. > > > > However, even further down the road we might need it (or something > > similar) anyway due to the thermal framework. At some point we would > > like to adjust the max capacity based any OPP constraints imposed by the > > thermal framework. In extreme cases big cpus might be capped so hard > > that they effectively have smaller capacity than little. I don't think > > it makes sense to re-normalize everything to the highest available > > capacity to ensure that there is always a cpu with capacity = 1024 in > > the system, instead we must be able to cope with scenarios where max > > capacity is smaller than 1024. > > Yes we will have to found a solution for thermal mitigation but i > don't know if a rd->max_cpu_capacity would the best solution Agreed, I'm pretty sure that the current form isn't sufficient. > > > > Also, for SMT max capacity is less than 1024 already. No? > > Yes, it is. I haven't looked in details but i think that we could use > a capacity of 1024 for SMT with changes that have been done on how to > evaluate if a sched_group is overloaded or not. Changing SMT is a bit more invasive that I had hoped for for this patch set. I will see if we can make it work with the current SMT capacities. > > > But we may be able to cater for this in wake_cap() somehow. I can have a > > look if Vincent doesn't like this patch. > > IMO, rd->max_cpu_capacity field doesn't seem to be required for now . No problem. I will try to get rid of it. I will drop the "arm:" patches as well as they would have to be extended to guarantee a max capacity of 1024 and we most likely will have to change it again when Juri's DT solution hopefully gets merged. Morten