From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
Sudeep Holla <sudeep.holla@arm.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Linux PM <linux-pm@vger.kernel.org>,
Ionela Voinescu <ionela.voinescu@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V4 2/2] cpufreq: cppc: Add support for frequency invariance
Date: Thu, 25 Feb 2021 10:14:09 +0530 [thread overview]
Message-ID: <20210225044409.t7dfaerwhttxukxa@vireshk-i7> (raw)
In-Reply-To: <CAJZ5v0i_JeMMAJA-J7ghuQr_+uN6urCGTn0O0FyZ8x8ntpKcJg@mail.gmail.com>
On 22-02-21, 16:57, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2021 at 12:20 PM Viresh Kumar <viresh.kumar@linaro.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
prev parent reply other threads:[~2021-02-25 4:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-22 11:18 [PATCH V4 0/2] cpufreq: cppc: Add support for frequency invariance Viresh Kumar
2021-02-22 11:18 ` [PATCH V4 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback Viresh Kumar
2021-02-22 11:18 ` [PATCH V4 2/2] cpufreq: cppc: Add support for frequency invariance Viresh Kumar
2021-02-22 15:57 ` Rafael J. Wysocki
2021-02-25 4:44 ` Viresh Kumar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210225044409.t7dfaerwhttxukxa@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=ionela.voinescu@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).