Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3831437yba; Tue, 7 May 2019 07:47:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqzuOhqVlZ82fRvYrpKeemWsbSt0oyhJ6Hg0hW9NL3/obqTQdYo6M/Q5yT05rj+WckeabhSC X-Received: by 2002:a65:610e:: with SMTP id z14mr16304084pgu.238.1557240434246; Tue, 07 May 2019 07:47:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557240434; cv=none; d=google.com; s=arc-20160816; b=nw0M0KfDx32Zlu5lFcd5qtc0U2eU2pNrTVBfq/fcf11ATewIhfOGKtJzi/lsqZdyyh qYUnnom9va7xuLSDo2YmR6flUoU4/6DGdWpjub71rAjMyaLD153hF1FfU3x9zu63jbiI k4DKNWDQVge40zFqYa1YoCqye3HHIwWGK+sDPOmJBRwMvbp1uIJXd0In7n/3qqRT0uB2 DcrPMKkJZ1LpNbnhdsSOTGyzTxvaE8oN7/5nY0Jb76II4RZMwj1p5V6+m4GImOxGvRFU NQlhb+/egrrrzd5AM9paeBdcQ1z8gXbmMwHvMnl9ac4cd+TxxAQVhkt/aW0Kkf8iI6iA P2uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=LVyi7ImUuQ+pMgcgM15WKfprLDflErXBDZ8Qd0Dvg2I=; b=D3ce6OGR1nPtjygdb2HYl8NzudgaU/AoiI/Z+R3avtbq9O2wE8GZ2vZoC80atT2BYf kngNu2ftJ1FeLyDxTqurTqxB+q2SLGBq8uFl5PyJvzmBzV6HPFg6d5v7/Np5oa4TNjky SWacJRya5r8gp34avXHZlWyYlXY0DKE+450FKXuVJ3lmygXKwCebT2hkOEJgzz7GYOLR VU6ipSWstEpplkmpcyRVVmwdeDOmJySipwPCne9JOwideojY/GDTiXVK7ciZFio2ajI2 643vPBrWkbwGP+ssr7k2DthkscVPpIXzvo6ZfbEzlLex/swcit1609GI74lRJ7nwKfJd Ux/w== 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 19si19242495pga.249.2019.05.07.07.46.58; Tue, 07 May 2019 07:47:14 -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 S1726836AbfEGOn6 (ORCPT + 99 others); Tue, 7 May 2019 10:43:58 -0400 Received: from ms01.santannapisa.it ([193.205.80.98]:55988 "EHLO mail.santannapisa.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726793AbfEGOn5 (ORCPT ); Tue, 7 May 2019 10:43:57 -0400 Received: from [83.43.182.198] (account l.abeni@santannapisa.it HELO nowhere) by santannapisa.it (CommuniGate Pro SMTP 6.1.11) with ESMTPSA id 138899088; Tue, 07 May 2019 16:43:56 +0200 Date: Tue, 7 May 2019 16:43:49 +0200 From: luca abeni To: Quentin Perret 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: <20190507164349.2823fdaa@nowhere> In-Reply-To: <20190507143125.cjfhdxngcugqmko3@queper01-lin> References: <20190506044836.2914-1-luca.abeni@santannapisa.it> <20190506044836.2914-2-luca.abeni@santannapisa.it> <20190507134850.yreebscc3zigfmtd@queper01-lin> <20190507162523.6a405d48@nowhere> <20190507143125.cjfhdxngcugqmko3@queper01-lin> Organization: Scuola Superiore S.Anna X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 May 2019 15:31:27 +0100 Quentin Perret wrote: > On Tuesday 07 May 2019 at 16:25:23 (+0200), luca abeni wrote: > > On Tue, 7 May 2019 14:48:52 +0100 > > Quentin Perret wrote: > > > > > 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 ? > > > > If I remember correctly, this function was called at boot time when > > the capacities are assigned to the CPU cores. > > > > I do not remember if the sched domain was re-built after this call, > > but I admit I do not know this part of the kernel very well... > > Right and things moved recently in this area, see bb1fbdd3c3fd > ("sched/topology, drivers/base/arch_topology: Rebuild the sched_domain > hierarchy when capacities change") Ah, thanks! I missed this change when rebasing the patchset. I guess this part of the patch has to be updated (and probably became useless?), then. Thanks, Luca > > > This achieved the effect of correctly setting up the "rd_capacity" > > field, but I do not know if there is a better/simpler way to achieve > > the same result :) > > OK, that's really an implementation detail, so no need to worry too > much about it at the RFC stage I suppose :-) > > Thanks, > Quentin