Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3768696yba; Tue, 7 May 2019 06:50:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqyUyjSdOLEIxfahyRTjBn9BqyfFdUkUbMS0sUqOzh5ZAqjL8rFGxMoEPqaHA5FqF3o1UUnV X-Received: by 2002:a63:c64a:: with SMTP id x10mr39864381pgg.195.1557237008125; Tue, 07 May 2019 06:50:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557237008; cv=none; d=google.com; s=arc-20160816; b=LUDCmjNLIVtQPMxEJsEgBoeklP9BG3fI7sxE5lheXS6H09LCpBJaMiHk2wOhdo39sm Ed8/bwF7Qu1TDZcmefDWL0OXzM1MLQcWubHJZ6su9PU6lvOE9N9W32lMxyTQzxxErFQa uvREvP+wbc6y7bF7zWDSJzbyrBBpSpBOO4Y+oX3gww8Ki7T/ldfp/9QYkrQyg5aeuAID 31mbJ+C/GAKxqRZbBLfcBg4DeNAsA2ap/fGn0NM6vzbMU9jbQDq7UbuKYwWe1xxpsajL aZbEfghPX3UEIICIsgo/eILLijfFw1pOCxqHAFbe1/+EFpBdvzMwMZyOUncpUH7oDSgK MdAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=U6ReBB+o+4IF8HLPqxocSNDL8hxbFN0D+dOc16QbAjQ=; b=IWFa1EO2Y91wPTi2XI7FWBD721HvYqtClDVCMy/QGXV/Jec1kfvSMceM2l0u1rtWDu 0B8RRMCkinhJSizQHNcow3RG/XKPggaiH3QCzFp7Py8kxA5zw90X8c3yXXJbD+8SRDIv PV6yjyrv7kx09ScIYwjrmA8ZtYmjWpzkyCN2rfJgIrZ7nx0X9gxmnqaMHZNXOlio3K4H ySPNlZ8gj4gwa7k5WXzsnSAYtDhPlCg3dgbAQSGJLEC1ZlucdoClZiCJqf5tYRXNMp7Y 8ByoX4mQPR527SYJUzL+Qof34p4KB4/CmNVXcLVz1BgZFWRL+7V9vTNF0nzf1XJkk4yy h+kw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b12si7095474pfd.79.2019.05.07.06.49.52; Tue, 07 May 2019 06:50:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726735AbfEGNs5 (ORCPT + 99 others); Tue, 7 May 2019 09:48:57 -0400 Received: from foss.arm.com ([217.140.101.70]:54862 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726516AbfEGNs5 (ORCPT ); Tue, 7 May 2019 09:48:57 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BC84580D; Tue, 7 May 2019 06:48:56 -0700 (PDT) Received: from queper01-lin (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E32A3F5C1; Tue, 7 May 2019 06:48:54 -0700 (PDT) Date: Tue, 7 May 2019 14:48:52 +0100 From: Quentin Perret To: Luca Abeni Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , "Rafael J . Wysocki" , Ingo Molnar , Peter Zijlstra , Vincent Guittot , "Paul E . McKenney" , Joel Fernandes , Luc Van Oostenryck , Morten Rasmussen , Juri Lelli , Daniel Bristot de Oliveira , Patrick Bellasi , Tommaso Cucinotta Subject: Re: [RFC PATCH 1/6] sched/dl: Improve deadline admission control for asymmetric CPU capacities Message-ID: <20190507134850.yreebscc3zigfmtd@queper01-lin> References: <20190506044836.2914-1-luca.abeni@santannapisa.it> <20190506044836.2914-2-luca.abeni@santannapisa.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190506044836.2914-2-luca.abeni@santannapisa.it> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Luca, On Monday 06 May 2019 at 06:48:31 (+0200), Luca Abeni wrote: > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index edfcf8d982e4..646d6d349d53 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -36,6 +36,7 @@ DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE; > > void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity) > { > + topology_update_cpu_capacity(cpu, per_cpu(cpu_scale, cpu), capacity); Why is that one needed ? Don't you end up re-building the sched domains after this anyways ? > per_cpu(cpu_scale, cpu) = capacity; > } Thanks, Quentin