linux-kernel - Re: [PATCH V4 2/2] cpufreq: cppc: Add support for frequency invariance

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] [day] [month] [year] [list]

Message-ID: <20210225044409.t7dfaerwhttxukxa@vireshk-i7>
Date:   Thu, 25 Feb 2021 10:14:09 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>,
        Sudeep Holla <sudeep.holla@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Ionela Voinescu <ionela.voinescu@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V4 2/2] cpufreq: cppc: Add support for frequency
 invariance

On 22-02-21, 16:57, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2021 at 12:20 PM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> Even though the driver is located in drivers/cpufreq/ CPPC is part of
> ACPI and so a CC to linux-acpi is missing.

I just used get-maintainers, perhaps we should add an entry for this
in MAINTAINERS, will be orphan though..

> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index e65e0a43be64..a3e2d6dfea70 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -19,6 +19,15 @@ config ACPI_CPPC_CPUFREQ
> >
> >           If in doubt, say N.
> >
> > +config ACPI_CPPC_CPUFREQ_FIE
> > +       bool "Frequency Invariance support for CPPC cpufreq driver"
> > +       depends on ACPI_CPPC_CPUFREQ
> 
> In theory, the CPPC cpufreq driver can be used on systems with
> nontrivial arch_freq_scale_tick() in which case the latter should be
> used I suppose.
> 
> Would that actually happen if this option is enabled?

IIUC, you are saying that if this driver runs on x86 then we want
arch_freq_scale_tick() from arch/x86/kernel/smpboot.c to run instead
of this ? Yes that will happen because x86 doesn't enable
CONFIG_GENERIC_ARCH_TOPOLOGY and so this code will never trigger.

For other cases, like ARM AMU counters, the arch specific
implementation takes precedence to this.

> > +static void __init cppc_freq_invariance_init(void)
> > +{
> > +       struct cppc_perf_fb_ctrs fb_ctrs = {0};
> > +       struct cppc_freq_invariance *cppc_fi;
> > +       struct sched_attr attr = {
> > +               .size           = sizeof(struct sched_attr),
> > +               .sched_policy   = SCHED_DEADLINE,
> > +               .sched_nice     = 0,
> > +               .sched_priority = 0,
> > +               /*
> > +                * Fake (unused) bandwidth; workaround to "fix"
> > +                * priority inheritance.
> > +                */
> > +               .sched_runtime  = 1000000,
> > +               .sched_deadline = 10000000,
> > +               .sched_period   = 10000000,
> > +       };
> > +       int i, ret;
> > +
> > +       if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate)
> > +               return;
> > +
> > +       kworker_fie = kthread_create_worker(0, "cppc_fie");
> > +       if (IS_ERR(kworker_fie))
> > +               return;
> > +
> > +       for_each_possible_cpu(i) {
> > +               cppc_fi = &per_cpu(cppc_freq_inv, i);
> > +
> > +               /* A policy failed to initialize, abort */
> > +               if (unlikely(!cppc_fi->cpu_data))
> > +                       return cppc_freq_invariance_exit();
> > +
> > +               kthread_init_work(&cppc_fi->work, cppc_scale_freq_workfn);
> > +               init_irq_work(&cppc_fi->irq_work, cppc_irq_work);
> 
> What would be wrong with doing the above in
> cppc_freq_invariance_policy_init()?  It looks like a better place to
> me.

Can move it there as well, I just kept policy specific stuff there as
ideally I wanted to do everything here.

> > +               ret = sched_setattr_nocheck(kworker_fie->task, &attr);
> 
> And this needs to be done only once if I'm not mistaken.

Yes, I failed to fix this when I went to a single kworker.

-- 
viresh