Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7002656ybi; Mon, 8 Jul 2019 12:28:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqzL68V0cQGHXNxhNKIv7rGpZDXjo2I9ww2bQm1fW/vUm5yrPKmCcS+ZZ4nMX6/PEE8txJTr X-Received: by 2002:a17:90a:ac0e:: with SMTP id o14mr28198617pjq.142.1562614109020; Mon, 08 Jul 2019 12:28:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562614109; cv=none; d=google.com; s=arc-20160816; b=JchaDsxst+W629aITWkz27+QoGBJ/EilvwrL1lBNoO/cMAFfWZ7r0cZjEgG7yTqnv7 NKxpq8L2QLGcxVEh0QFaTzECzJXUhkC1wmOzA1oHIirjb9r8brmIwQdNhvuvj1sIUMae Ei7dKrfApCxrjTmsDRW+Nxk8gAvRjcPeYfrqxvWZoKAXSy0QBJXllzxrIeZ+ONYS0vWr gSKTPWC8yMq2qsMNs5k93j/lo5QozOyPLSrxtwQdxrewC4dRp6vjBRzGnU4/h5NVSygX GSLXdLNRrDY/BZXb+bukwsBUlNvsXCu5NZfEOwSVPXc9D7IvZLL+W0pRngqOMdvwAyA6 ruSA== 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=U8lq1VoMWYA7ECMDdC5J9Hy4ClSFG7P9jjyxq+a/juc=; b=VW4MMaAqK3uMloxFruMhRopx44EIT9EHGmonGSfyLSVtlP0jhKRGWyAeei73wHplaN JrB/HWNJIczJrf8egAB+gQFYejkkDM48yVI1gfugwPjZCNa7yy3WqPeQvq/VCanKFxgR Ao4svzO2mTBnNJTAWKr7Ys9G0IPaRUCp1srnmxzHZobdYu/9JC24oc0yhRUjc8fcjFmA cWkLnCdLGi+rVg5B70gFXiXjDI3g2uAXPW0EObavMcxprDUYbCLF24Plisp83Y/X47/F WZowjEQin4EVgk4J07aucmyT1cvaXslrQtQQGsaiHd8XEnQ360S489tD6l2lwbey+f2H BNOg== 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 bh8si18063878plb.175.2019.07.08.12.28.14; Mon, 08 Jul 2019 12:28:28 -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 S1732113AbfGHPF7 (ORCPT + 99 others); Mon, 8 Jul 2019 11:05:59 -0400 Received: from foss.arm.com ([217.140.110.172]:50370 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729189AbfGHPF6 (ORCPT ); Mon, 8 Jul 2019 11:05:58 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4CC312B; Mon, 8 Jul 2019 08:05:58 -0700 (PDT) Received: from queper01-lin (unknown [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 469E23F59C; Mon, 8 Jul 2019 08:05:56 -0700 (PDT) Date: Mon, 8 Jul 2019 16:05:55 +0100 From: Quentin Perret To: Dietmar Eggemann Cc: luca abeni , 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: <20190708150552.rjdjqnnwijmliaoe@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> <20190507164349.2823fdaa@nowhere> <3ddfc5ce-8870-a8d5-265a-462763fb348c@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ddfc5ce-8870-a8d5-265a-462763fb348c@arm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 08 Jul 2019 at 13:22:35 (+0200), Dietmar Eggemann wrote: > On 5/7/19 4:43 PM, luca abeni wrote: > > 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: > > [...] > > >> 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. > > [...] > > >>> 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 :-) > > What about we integrate the code to calculate the rd capacity into > build_sched_domains() (next to the code to establish the rd > max_cpu_capacity)? Right, that's also what Vincent suggested IIRC. I think that'd work :) Thanks, Quentin