Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp621276pxb; Wed, 25 Aug 2021 10:55:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEXn/n7P9eA2z3B8JDfXJbZjO0mstj4vu6Ka5MJoKMZC0hWVIGHRhgejAKr8g9TQQjNvts X-Received: by 2002:a05:6602:117:: with SMTP id s23mr16684263iot.124.1629914136802; Wed, 25 Aug 2021 10:55:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629914136; cv=none; d=google.com; s=arc-20160816; b=sK1YbF6Hoo2w4fNJCEcFkiVwStRfw0zSmRHqGlRgCy+CePB4O5qDDGKBIaMgSxUVyY dxFzWSXk5+5eAac1TSEpUk/7naBRbsLfi/zCi7YhUVm87SBBenUKQqxlgpbXuz3/XUQ3 QvTKGEP0cdckHdD7crte9InhfJGEcTluT04sW0hjTTK1F2js9x/k00uKB3NW+ut06doO Cu4bUqUlF18MOXrGdum9BgATeXI/TRu5vTTU7Vw38tBn3GNnPKL8Z41Q64d3m22VR8o1 klGWu7Ogo04UM5KihB5pJGAGb6m10NJmPnhZENaZJqMrkUqR/Gr0sgd+xoAQnYZguzJW x9lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=df/OerwKAWPLPQITF2yDRoTeJU9NwWh+Y/yCNdwz/ko=; b=JRRtPtglJGndWTkbN3lunyI6iieO7dlaXSRH7pYW8TNyCO5fyhMbIcKRTnz3a2neFf 59vXYcIdF+4SBr8lIqSPddP7CZGk0PLlyJqN6zxtXT8OE4VDPrUWYOz6OpNMCtmShvBL ridZ4N9tUSxlNZo1Ldum2MZPfkg/J/UpXwBXrCMHhdg2JsSNp0fSzzGK4XoesCWZVZ2C H8SJd9/xKqWWjR8TFcKeZIQyVeasR1P8JAcyjoH1XJn4EnUQvZBnJBf4WjuRyyChWRl2 FjUVvDqOm2ur0QWOATD6fa9X0+JfuDwi2CrE8Z4tBkMc3aISccxAbL/pK3kgEXm3hN7J KPaA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i11si446525ilm.28.2021.08.25.10.55.19; Wed, 25 Aug 2021 10:55:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234816AbhHYRzY (ORCPT + 99 others); Wed, 25 Aug 2021 13:55:24 -0400 Received: from mail-oo1-f52.google.com ([209.85.161.52]:40675 "EHLO mail-oo1-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231962AbhHYRzX (ORCPT ); Wed, 25 Aug 2021 13:55:23 -0400 Received: by mail-oo1-f52.google.com with SMTP id j11-20020a4a92cb000000b002902ae8cb10so58864ooh.7; Wed, 25 Aug 2021 10:54:37 -0700 (PDT) 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=df/OerwKAWPLPQITF2yDRoTeJU9NwWh+Y/yCNdwz/ko=; b=I4vFIBZiZ0IVvOBOtgacSGIl3cwGeMfk3O6X5UJweFgZOK4YYqgFrJ/XBskc1XRBeB mxcvE71JWAQDa0lmMF0gzo4HuwYbrr8yKVjt5E7I0CFAjYI8K0AgwNP39KIpntnb2/0d 1Al2cxDThdOVwQnTgsdh/R5RP8ti51SzfBibD9GxFFKE08hWV9OPUXmy9Jz/xfhi5Ev/ zaefV40IKH/sKIEdPHo5Mnxpvh8Xo2/C5AhQ4amGZDlRa+eBwm1DxqSAmSeHRBOmxTu5 eXQRhrZg/BcS8e+Y4Bi1l6sVcmUkpUw81MPjfdZ5jJn2/TRwW8SrjffzuAyTlPqZ98XQ /2fA== X-Gm-Message-State: AOAM530wgZNyl5Xaan0rNDtxdyC/FnPzIPaf4tBBBIfO+Q/SCyBm6v5I e8tKNj+UwESM2kh0oZ/jwgZ3hnldtBgBfDWBWcw= X-Received: by 2002:a4a:a552:: with SMTP id s18mr35593004oom.1.1629914077598; Wed, 25 Aug 2021 10:54:37 -0700 (PDT) MIME-Version: 1.0 References: <20210824105651.28660-1-ionela.voinescu@arm.com> <20210824105651.28660-3-ionela.voinescu@arm.com> In-Reply-To: <20210824105651.28660-3-ionela.voinescu@arm.com> From: "Rafael J. Wysocki" Date: Wed, 25 Aug 2021 19:54:26 +0200 Message-ID: Subject: Re: [PATCH v2 2/3] arch_topology: obtain cpu capacity using information from CPPC To: Ionela Voinescu Cc: Sudeep Holla , "Rafael J . Wysocki" , Thomas Gleixner , Ingo Molnar , Giovanni Gherdovich , Catalin Marinas , Will Deacon , Valentin Schneider , Dietmar Eggemann , Sean Kelley , Linux Kernel Mailing List , ACPI Devel Maling List , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 24, 2021 at 12:57 PM Ionela Voinescu wrote: > > Define topology_init_cpu_capacity_cppc() to use highest performance > values from _CPC objects to obtain and set maximum capacity information > for each CPU. acpi_cppc_processor_probe() is a good point at which to > trigger the initialization of CPU (u-arch) capacity values, as at this > point the highest performance values can be obtained from each CPU's > _CPC objects. Architectures can therefore use this functionality > through arch_init_invariance_cppc(). > > The performance scale used by CPPC is a unified scale for all CPUs in > the system. Therefore, by obtaining the raw highest performance values > from the _CPC objects, and normalizing them on the [0, 1024] capacity > scale, used by the task scheduler, we obtain the CPU capacity of each > CPU. > > While an ACPI Notify(0x85) could alert about a change in the highest > performance value, which should in turn retrigger the CPU capacity > computations, this notification is not currently handled by the ACPI > processor driver. When supported, a call to arch_init_invariance_cppc() > would perform the update. > > Signed-off-by: Ionela Voinescu > Tested-by: Valentin Schneider > Cc: Sudeep Holla > --- > drivers/base/arch_topology.c | 37 +++++++++++++++++++++++++++++++++++ > include/linux/arch_topology.h | 4 ++++ > 2 files changed, 41 insertions(+) > > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index 921312a8d957..358e22cd629e 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -306,6 +306,43 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu) > return !ret; > } > > +#ifdef CONFIG_ACPI_CPPC_LIB > +#include > + > +void topology_init_cpu_capacity_cppc(void) > +{ > + struct cppc_perf_caps perf_caps; > + int cpu; > + > + if (likely(acpi_disabled || !acpi_cpc_valid())) > + return; > + > + raw_capacity = kcalloc(num_possible_cpus(), sizeof(*raw_capacity), > + GFP_KERNEL); > + if (!raw_capacity) > + return; > + > + for_each_possible_cpu(cpu) { > + if (!cppc_get_perf_caps(cpu, &perf_caps)) { > + raw_capacity[cpu] = perf_caps.highest_perf; From experience, I would advise doing some sanity checking on the per_caps values before using them here. Also note that highest_perf may not be sustainable, so would using highest_perf as raw_capacity[] always work as expected? > + pr_debug("cpu_capacity: CPU%d cpu_capacity=%u (raw).\n", > + cpu, raw_capacity[cpu]); > + } else { > + pr_err("cpu_capacity: CPU%d missing highest performance.\n", cpu); > + pr_err("cpu_capacity: partial information: fallback to 1024 for all CPUs\n"); > + goto exit; > + } > + } > + > + topology_normalize_cpu_scale(); > + schedule_work(&update_topology_flags_work); > + pr_debug("cpu_capacity: cpu_capacity initialization done\n"); > + > +exit: > + free_raw_capacity(); > +} > +#endif > + > #ifdef CONFIG_CPU_FREQ > static cpumask_var_t cpus_to_visit; > static void parsing_done_workfn(struct work_struct *work); > diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h > index f180240dc95f..9cf1a17938f0 100644 > --- a/include/linux/arch_topology.h > +++ b/include/linux/arch_topology.h > @@ -11,6 +11,10 @@ > void topology_normalize_cpu_scale(void); > int topology_update_cpu_topology(void); > > +#ifdef CONFIG_ACPI_CPPC_LIB > +void topology_init_cpu_capacity_cppc(void); > +#endif > + > struct device_node; > bool topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu); > > -- > 2.29.2.dirty >