From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751262AbcGMQgQ (ORCPT ); Wed, 13 Jul 2016 12:36:16 -0400 Received: from foss.arm.com ([217.140.101.70]:37832 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750872AbcGMQgK (ORCPT ); Wed, 13 Jul 2016 12:36:10 -0400 Date: Wed, 13 Jul 2016 17:37:24 +0100 From: Morten Rasmussen To: Dietmar Eggemann Cc: Vincent Guittot , 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: <20160713163723.GC21816@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <578646A8.1070607@arm.com> 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 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. Also, for SMT max capacity is less than 1024 already. No? 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. Cheers, Morten