Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp212630pxb; Wed, 3 Feb 2021 03:47:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJyyYVpcTneaKiC7KQawhWjn2/QPWnT5CbhDQBbg9k4t2esh03NtV24K3FgBU3SdmNdHvoBo X-Received: by 2002:a17:906:39d0:: with SMTP id i16mr2794216eje.18.1612352827333; Wed, 03 Feb 2021 03:47:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612352827; cv=none; d=google.com; s=arc-20160816; b=z/LokiNTA3wDmMXtV0wNEq9RTdiBi8khOyBddm4a9oa+To3vaxEj6NtiJbGn+rfxoW wzW2lJn8Ioj4z6+duSqqbsrLaNe9Wc+kfCyx4DYZJXUYuHSZ4T98H6nnci6ma0xbe2e6 QJConYWPGcJttPUyT89oL5PqwBN9nRi9c0w7Diu2IQLvWGFBps1iRV8UmMc4S+H5hzRZ 3cRTp4Q5oCJNqmYg1AByct3pLP+/oNVB8RdihbFt+AJUktbEQLtkYw8ZEULfrfBazxzl C2FMclr+cOrNcqDFNexP95HBCo52MjPmu1kILxqRqhjxRmBeg2JgWiC4T3i8PSuJ21c9 TO2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=RYzvMmDxoqILF1NJGB0ZMswcde8ruhyH9G5NuW7ZlkY=; b=qR1OdXgjuL7fPSVpeH2+dtMKccI3KooPAFPfm4X5mb42mUic4ZcvLAAAwONoivPOyK taY8YwQJAR61KgAsVoD6ka9F0NRzqupcZE4/bNIRV5iPTMKTm0rExPfnV/kjgqD8kkWh 4+vbZw6YlyO4lWPc4ol6EzdwnxzsSH5bsdGcbxUCKFe7AMc0dME1MkUX8GQAu3V+ONzL ChU5WgPxrip+6/A34B6BY73Pj9bP2dqv4zAAeW7qGrv5LeZVWtBjaumvchknmfkV2X/c Leq9Gco/mxS7AYqT0wmXFSMINlo/gXetzxqUHfw+3x+xMuU2uP3C1VVrAcmQov8cReGD x9UA== 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a3si1051405edn.482.2021.02.03.03.46.42; Wed, 03 Feb 2021 03:47:07 -0800 (PST) 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234292AbhBCLqK (ORCPT + 99 others); Wed, 3 Feb 2021 06:46:10 -0500 Received: from foss.arm.com ([217.140.110.172]:38546 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234227AbhBCLqJ (ORCPT ); Wed, 3 Feb 2021 06:46:09 -0500 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 32569D6E; Wed, 3 Feb 2021 03:45:23 -0800 (PST) Received: from localhost (unknown [10.1.198.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C65523F719; Wed, 3 Feb 2021 03:45:22 -0800 (PST) Date: Wed, 3 Feb 2021 11:45:21 +0000 From: Ionela Voinescu To: Viresh Kumar Cc: Rafael Wysocki , Catalin Marinas , Will Deacon , Vincent Guittot , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, Sudeep Holla , Greg Kroah-Hartman Subject: Re: [PATCH V3 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback Message-ID: <20210203114521.GA6380@arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Viresh, Many thanks for the renaming of functions/variables/enums. I've cropped all the code that looks good to me, and I kept some portions of interest. On Thursday 28 Jan 2021 at 16:18:55 (+0530), Viresh Kumar wrote: > This patch attempts to make it generic enough so other parts of the > kernel can also provide their own implementation of scale_freq_tick() > callback, which is called by the scheduler periodically to update the > per-cpu freq_scale variable. [..] > static void amu_fie_setup(const struct cpumask *cpus) > { > @@ -227,7 +263,7 @@ static void amu_fie_setup(const struct cpumask *cpus) > if (!invariant && !cpumask_equal(amu_fie_cpus, cpu_present_mask)) > return; > > - static_branch_enable(&amu_fie_key); > + topology_set_scale_freq_source(&amu_sfd, amu_fie_cpus); > > pr_debug("CPUs[%*pbl]: counters will be used for FIE.", > cpumask_pr_args(cpus)); > @@ -283,53 +319,6 @@ static int __init init_amu_fie(void) > } > core_initcall(init_amu_fie); [..] > +void topology_set_scale_freq_source(struct scale_freq_data *data, > + const struct cpumask *cpus) > +{ > + struct scale_freq_data *sfd; > + int cpu; > + > + for_each_cpu(cpu, cpus) { > + sfd = per_cpu(sft_data, cpu); > + > + /* Use ARCH provided counters whenever possible */ > + if (!sfd || sfd->source != SCALE_FREQ_SOURCE_ARCH) { > + per_cpu(sft_data, cpu) = data; > + cpumask_set_cpu(cpu, &scale_freq_counters_mask); > + } > + } > } > +EXPORT_SYMBOL_GPL(topology_set_scale_freq_source); [..] I have one single comment left for this patch, and apologies in advance for the long story. In general, for frequency invariance, we're interested in whether the full system is frequency invariant as well, for two reasons: - We want to be able to either set a scale factor for all CPUs or none at all. - If at some point during the boot process the system invariance status changes, we want to be able to inform dependents: schedutil and EAS. This management is currently done on amu_fie_setup(), because before these patches we only had two sources for frequency invariance: cpufreq and AMU counters. But that's not enough after these two patches, from both functional and code design point of view. I have to mention that your code will work as it is for now, but only because CPPC is the new other source of counters, and for CPPC we also have cpufreq invariance available. But this only hides what can become a problem later: if in the future we won't have cpufreq invariance for CPPC or if another provider of counters is added and used in a system without cpufreq invariance, the late initialization of these counters will either break schedutil/scheduler if not all CPUs support those counters, or keep EAS disabled, even if all CPUs support these counters, and frequency invariance is later enabled. Therefore, I think system level invariance management (checks and call to rebuild_sched_domains_energy()) also needs to move from arm64 code to arch_topology code. Thanks, Ionela.