Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1002197ybb; Wed, 8 Apr 2020 14:21:03 -0700 (PDT) X-Google-Smtp-Source: APiQypI4mZJm7Mn4BamnHy8T0FxPuag2M7kzh30JxOyCokwr6R0H2IsFIihUn7JDiij5THJTEHrf X-Received: by 2002:a9d:65d3:: with SMTP id z19mr7216491oth.314.1586380862815; Wed, 08 Apr 2020 14:21:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586380862; cv=none; d=google.com; s=arc-20160816; b=AAU1ujVla4kb5v+7qm8R06G68eBaXSGNzCtTw/ObaYhA+1wSL5vMrdAYd+pehHK4Bc qkjlbbtNY7JYEW5CymI3JAH1BQ0GYlynz/azq3xsl42GVcr996Pxpx+ZWLCMDkvtM7VI Hj7fko/yE59wGIbhWQ0y41PVuLxQ5X2+EqQqsckXDzmyPfdlfpMK5SvW3vTdLZjLayyh PNhk9KO5izQJoS+6syhkXSzZNkrRsTjQZnRnNksRYjvahxFHZU/JPXq4P2/zLK6QwXw1 JJ6ymnweaotAqOkVAn2kiPtPkpZJa2NLLycYO/Xp5WRRxY4o2Dqk3U+QsS+iBSF1QmuJ U2hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=nGglepjmycB/unQeYfbl18WIvTQ2qrXEhsStCYUcvCs=; b=PeZYS9UliFXp+Xhkhv2EiGEP3FpFHKUKASJxybLzj7u/FO87LC5aqTTO9RV88ZKvPw GmPEUR16QSa+ell9ePhLCr+jiv+ITFhLJUUmlxUC9WTAM5URSP7WjnvrSCPm4oKLS/ZX JF3QNC5Sd0ePW0fq5Y/ALjXU7BzTTrE5pOsVPDEB7GAMWSA4blZfwCKS/RBVaOBIvy7N dKADDDpiMY1A3zhVhGICZZKkrPSNnbb697/rWnajHlIPMYGI6I1yCB9QGBlRBfrwJkCL 8WtB8KN4zZ1pyeqqyPmOz6rVzgSajSpZDys72Y50EEEyeP3T5oRxCwVT65hb/6QdfEGW WZ1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=uLq7Ypyg; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d14si1438311oth.304.2020.04.08.14.20.49; Wed, 08 Apr 2020 14:21:02 -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; dkim=pass header.i=@linaro.org header.s=google header.b=uLq7Ypyg; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729537AbgDHREO (ORCPT + 99 others); Wed, 8 Apr 2020 13:04:14 -0400 Received: from mail-lf1-f68.google.com ([209.85.167.68]:45854 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726550AbgDHREO (ORCPT ); Wed, 8 Apr 2020 13:04:14 -0400 Received: by mail-lf1-f68.google.com with SMTP id f8so5668896lfe.12 for ; Wed, 08 Apr 2020 10:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nGglepjmycB/unQeYfbl18WIvTQ2qrXEhsStCYUcvCs=; b=uLq7Ypyg4WR6l91r0+uGFO2S9ospCFtjto42uvZSuUD9ukRkdLaLxiqx62UPv9rkwq xH6oS0WlJdRqLEaIUERf3hI4fErWYsjn+kceTusdjGkQOWwh/O5UY+un7xAueXOKQRjV WnLVzhGAtgqx4Rc1OUqWOii0yN4SDSWAPuYgIrpANlb48DR5v0e9IAig2Q1FBlev81ph oEkfxkWt/lQUzB7e1KRHqkguALpG0g/UzZldFF4LO8/PrBoGIJIdpNMHAMDOCyog1jJQ 5RHmBtiSExHPdE5cO0pyEg5Ku4aDdsZDVnEE1ZV1s7ERUJBghFp0JL/753gjZsGiFWHv eJmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nGglepjmycB/unQeYfbl18WIvTQ2qrXEhsStCYUcvCs=; b=a1JFgIGbiysKpIjMdvhUZ8/NxULw3Xbt+2Fk4xm54YyXhbi1xyKlp8nQNoHDd4S9V2 jyA66sTdKMsB1dQC9M6Ft8DVkNvqvr3xS8wjJ/BJRKwLkX0XtQRv43ehLRrtCA+AisE1 T28T5wPzdplnCfk3HjS6EhAs/cWr9yQTk0DLoAM9KGN5sibLbmnuWmxY/qac9yqwc2/6 KNBjtnBaCgPK0a2cn8SwUmozzZV1mcZwKG09Xwi40w6GkRRkxYKxgZlshKwWgyBgSUz7 MX6f5Fa2XXFAB4uS3Y8AjAQpDC+UfwuQtjIghCrg07LnkNizBJhkPm1TmdioLEjsyUrD jC0w== X-Gm-Message-State: AGi0PubIhUNEE76u2+Xe4HMaaKLf7CDa84pukAfR6yzgZqQCJPHmxbm8 nkrSZaR39FigZsVxQCA37K5Lb4DK6xJxfkTjpDHntQ== X-Received: by 2002:ac2:58ee:: with SMTP id v14mr4872095lfo.25.1586365449621; Wed, 08 Apr 2020 10:04:09 -0700 (PDT) MIME-Version: 1.0 References: <20200408095012.3819-1-dietmar.eggemann@arm.com> <20200408095012.3819-2-dietmar.eggemann@arm.com> <42cc3878-4c57-96ba-3ebd-1b4d4ef87fae@arm.com> In-Reply-To: <42cc3878-4c57-96ba-3ebd-1b4d4ef87fae@arm.com> From: Vincent Guittot Date: Wed, 8 Apr 2020 19:03:57 +0200 Message-ID: Subject: Re: [PATCH 1/4] sched/topology: Store root domain CPU capacity sum To: Dietmar Eggemann Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Steven Rostedt , Luca Abeni , Daniel Bristot de Oliveira , Wei Wang , Quentin Perret , Alessio Balsini , Pavan Kondeti , Patrick Bellasi , Morten Rasmussen , Valentin Schneider , Qais Yousef , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 Apr 2020 at 18:31, Dietmar Eggemann wrote: > > On 08.04.20 14:29, Vincent Guittot wrote: > > On Wed, 8 Apr 2020 at 11:50, Dietmar Eggemann wrote: > > [...] > > >> /** > >> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > >> index 8344757bba6e..74b0c0fa4b1b 100644 > >> --- a/kernel/sched/topology.c > >> +++ b/kernel/sched/topology.c > >> @@ -2052,12 +2052,17 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att > >> /* Attach the domains */ > >> rcu_read_lock(); > >> for_each_cpu(i, cpu_map) { > >> + unsigned long cap = arch_scale_cpu_capacity(i); > > > > Why do you replace the use of rq->cpu_capacity_orig by > > arch_scale_cpu_capacity(i) ? > > There is nothing about this change in the commit message > > True. And I can change this back. > > It seems though that the solution is not sufficient because of the > 'rd->span &nsub cpu_active_mask' issue discussed under patch 2/4. > > But this remind me of another question I have. > > Currently we use arch_scale_cpu_capacity() more often (16 times) than > capacity_orig_of()/rq->cpu_capacity_orig . > > What's hindering us to remove rq->cpu_capacity_orig and the code around > it and solely rely on arch_scale_cpu_capacity()? I mean the arch > implementation should be fast. Or we can do the opposite and only use capacity_orig_of()/rq->cpu_capacity_orig. Is there a case where the max cpu capacity changes over time ? So I would prefer to use cpu_capacity_orig which is a field of scheduler instead of always calling an external arch specific function