linux-kernel - Re: [PATCH v3 1/2] ACPI: CPPC: Disable FIE if registers in PCC regions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220830032739.m4jw2tcjrdmxvid7@vireshk-i7>
Date:   Tue, 30 Aug 2022 08:57:39 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Lukasz Luba <lukasz.luba@....com>, vincent.guittot@...aro.org
Cc:     Jeremy Linton <jeremy.linton@....com>, rafael@...nel.or,
        lenb@...nel.org, robert.moore@...el.com,
        punit.agrawal@...edance.com, ionela.voinescu@....com,
        pierre.gondois@....com, linux-kernel@...r.kernel.org,
        devel@...ica.org, linux-pm@...r.kernel.org,
        linux-acpi@...r.kernel.org,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Souvik Chakravarty <souvik.chakravarty@....com>
Subject: Re: [PATCH v3 1/2] ACPI: CPPC: Disable FIE if registers in PCC
 regions

+Vincent.

On 24-08-22, 15:41, Lukasz Luba wrote:
> Hi Jeremy,
> 
> +CC Dietmar, Morten and Souvik
> 
> On 8/18/22 22:16, Jeremy Linton wrote:
> > PCC regions utilize a mailbox to set/retrieve register values used by
> > the CPPC code. This is fine as long as the operations are
> > infrequent. With the FIE code enabled though the overhead can range
> > from 2-11% of system CPU overhead (ex: as measured by top) on Arm
> > based machines.
> > 
> > So, before enabling FIE assure none of the registers used by
> > cppc_get_perf_ctrs() are in the PCC region. Furthermore lets also
> > enable a module parameter which can also disable it at boot or module
> > reload.
> > 
> > Signed-off-by: Jeremy Linton <jeremy.linton@....com>
> > ---
> >   drivers/acpi/cppc_acpi.c       | 41 ++++++++++++++++++++++++++++++++++
> >   drivers/cpufreq/cppc_cpufreq.c | 31 +++++++++++++++++++++----
> >   include/acpi/cppc_acpi.h       |  5 +++++
> >   3 files changed, 73 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> > index 1e15a9f25ae9..c840bf606b30 100644
> > --- a/drivers/acpi/cppc_acpi.c
> > +++ b/drivers/acpi/cppc_acpi.c
> > @@ -1240,6 +1240,47 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps)
> >   }
> >   EXPORT_SYMBOL_GPL(cppc_get_perf_caps);
> > +/**
> > + * cppc_perf_ctrs_in_pcc - Check if any perf counters are in a PCC region.
> > + *
> > + * CPPC has flexibility about how counters describing CPU perf are delivered.
> > + * One of the choices is PCC regions, which can have a high access latency. This
> > + * routine allows callers of cppc_get_perf_ctrs() to know this ahead of time.
> > + *
> > + * Return: true if any of the counters are in PCC regions, false otherwise
> > + */
> > +bool cppc_perf_ctrs_in_pcc(void)
> > +{
> > +	int cpu;
> > +
> > +	for_each_present_cpu(cpu) {
> > +		struct cpc_register_resource *ref_perf_reg;
> > +		struct cpc_desc *cpc_desc;
> > +
> > +		cpc_desc = per_cpu(cpc_desc_ptr, cpu);
> > +
> > +		if (CPC_IN_PCC(&cpc_desc->cpc_regs[DELIVERED_CTR]) ||
> > +		    CPC_IN_PCC(&cpc_desc->cpc_regs[REFERENCE_CTR]) ||
> > +		    CPC_IN_PCC(&cpc_desc->cpc_regs[CTR_WRAP_TIME]))
> > +			return true;
> > +
> > +
> > +		ref_perf_reg = &cpc_desc->cpc_regs[REFERENCE_PERF];
> > +
> > +		/*
> > +		 * If reference perf register is not supported then we should
> > +		 * use the nominal perf value
> > +		 */
> > +		if (!CPC_SUPPORTED(ref_perf_reg))
> > +			ref_perf_reg = &cpc_desc->cpc_regs[NOMINAL_PERF];
> > +
> > +		if (CPC_IN_PCC(ref_perf_reg))
> > +			return true;
> > +	}
> 
> Do we have a platform which returns false here?
> 
> > +	return false;
> > +}
> > +EXPORT_SYMBOL_GPL(cppc_perf_ctrs_in_pcc);
> > +
> >   /**
> >    * cppc_get_perf_ctrs - Read a CPU's performance feedback counters.
> >    * @cpunum: CPU from which to read counters.
> > diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> > index 24eaf0ec344d..32fcb0bf74a4 100644
> > --- a/drivers/cpufreq/cppc_cpufreq.c
> > +++ b/drivers/cpufreq/cppc_cpufreq.c
> > @@ -63,7 +63,15 @@ static struct cppc_workaround_oem_info wa_info[] = {
> >   static struct cpufreq_driver cppc_cpufreq_driver;
> > +static enum {
> > +	FIE_UNSET = -1,
> > +	FIE_ENABLED,
> > +	FIE_DISABLED
> > +} fie_disabled = FIE_UNSET;
> > +
> >   #ifdef CONFIG_ACPI_CPPC_CPUFREQ_FIE
> > +module_param(fie_disabled, int, 0444);
> > +MODULE_PARM_DESC(fie_disabled, "Disable Frequency Invariance Engine (FIE)");
> 
> Why we need the modules support?
> I would drop this, since the fie_disabled would be set properly when
> needed. The code would be cleaner (more below).
> 
> >   /* Frequency invariance support */
> >   struct cppc_freq_invariance {
> > @@ -158,7 +166,7 @@ static void cppc_cpufreq_cpu_fie_init(struct cpufreq_policy *policy)
> >   	struct cppc_freq_invariance *cppc_fi;
> >   	int cpu, ret;
> > -	if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate)
> > +	if (fie_disabled)
> >   		return;
> >   	for_each_cpu(cpu, policy->cpus) {
> > @@ -199,7 +207,7 @@ static void cppc_cpufreq_cpu_fie_exit(struct cpufreq_policy *policy)
> >   	struct cppc_freq_invariance *cppc_fi;
> >   	int cpu;
> > -	if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate)
> > +	if (fie_disabled)
> >   		return;
> >   	/* policy->cpus will be empty here, use related_cpus instead */
> > @@ -229,7 +237,21 @@ static void __init cppc_freq_invariance_init(void)
> >   	};
> >   	int ret;
> > -	if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate)
> > +	switch (fie_disabled) {
> > +	/* honor user request */
> > +	case FIE_DISABLED:
> > +	case FIE_ENABLED:
> 
> This module's over-write doesn't look 'clean'.
> Is it OK to allow a user to go with the poor performing
> system (likely on many platforms)? Or we assume that there are
> platforms which has a bit faster mailboxes and they already
> have the FIE issue impacting task's utilization measurements.
> 
> It looks like we are not sure about the solution. On one hand
> we implement those checks in the cppc_perf_ctrs_in_pcc()
> which could set the flag, but on the other hand we allow user
> to decide. IMO this creates diversity that we are not able to control.
> It creates another tunable knob in the kernel, which then is forgotten
> to check.
> 
> I still haven't seen information that the old FIE was an issue on those
> servers and had impact on task utilization measurements. This should be
> a main requirement for this new feature. This would be after we proved
> that the utilization problem was due to the FIE and not something else (like
> uArch variation or workload variation).
> 
> IMO let's revert the ACPI_CPPC_CPUFREQ_FIE. When we get data that
> FIE is an issue on those servers we can come back to this topic.
> 
> Regards,
> Lukasz

-- 
viresh