All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Dmitry Osipenko <digetx@gmail.com>,
	Rafael Wysocki <rjw@rjwysocki.net>,
	Linux PM <linux-pm@vger.kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Pavel Machek <pavel@ucw.cz>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH V7 5/7] cpufreq: Register notifiers with the PM QoS framework
Date: Wed, 16 Oct 2019 13:57:42 +0530	[thread overview]
Message-ID: <20191016082742.nttzuofes6uds4pu@vireshk-i7> (raw)
In-Reply-To: <CAJZ5v0hxsy3ZKFvtWULHAVog4=3rYQfd3-61A9dNaKeUbiDtrg@mail.gmail.com>

On 15-10-19, 23:50, Rafael J. Wysocki wrote:
> On Tue, Oct 15, 2019 at 5:53 PM Rafael J. Wysocki <rafael@kernel.org> wrote:

> > > - Update QoS framework with the knowledge of related CPUs, this has been pending
> > >   until now from my side. And this is the thing we really need to do. Eventually
> > >   we shall have only a single notifier list for all CPUs of a policy, at least
> > >   for MIN/MAX frequencies.
> >
> > - Move the PM QoS requests and notifiers to the new policy CPU on all
> > changes of that.  That is, when cpufreq_offline() nominates the new
> > "leader", all of the QoS stuff for the policy needs to go to this one.
> 
> Alas, that still will not work, because things like
> acpi_processor_ppc_init() only work accidentally for one-CPU policies.

I am not sure what problem you see here ? Can you please explain a bit more.

> Generally, adding such a PM QoS request to a non-policy CPU simply has
> no effect until it becomes a policy CPU which may be never.

I was thinking maybe we can read the constraints for all CPUs in the
policy->cpus mask in cpufreq_set_policy() and so this part of the problem will
just go away. The only part that would be left is to remove the QoS constraints
properly.

> It looks like using device PM QoS for cpufreq is a mistake in general
> and what is needed is a struct pm_qos_constraints member in struct
> cpufreq_policy and something like
> 
> struct freq_pm_qos_request {
>         enum freq_pm_qos_req_type type; /* min or max */
>         struct plist_node pnode;
>         struct cpufreq_policy *policy;
> };
> 
> Then, pm_qos_update_target() can be used for adding, updating and
> removing requests.

-- 
viresh

  reply	other threads:[~2019-10-16  8:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-04  7:36 [PATCH V6 0/7] cpufreq: Use QoS layer to manage freq-constraints Viresh Kumar
2019-07-04  7:36 ` [PATCH V6 1/7] PM / QOS: Pass request type to dev_pm_qos_{add|remove}_notifier() Viresh Kumar
2019-07-04  7:36 ` [PATCH V6 2/7] PM / QOS: Rename __dev_pm_qos_read_value() and dev_pm_qos_raw_read_value() Viresh Kumar
2019-07-04  7:36 ` [PATCH V6 3/7] PM / QOS: Pass request type to dev_pm_qos_read_value() Viresh Kumar
2019-07-04  7:36 ` [PATCH V6 4/7] PM / QoS: Add support for MIN/MAX frequency constraints Viresh Kumar
2019-07-04  7:36 ` [PATCH V6 5/7] cpufreq: Register notifiers with the PM QoS framework Viresh Kumar
2019-07-08 10:57   ` [PATCH V7 " Viresh Kumar
2019-09-22 20:12     ` Dmitry Osipenko
2019-09-23 13:56       ` Viresh Kumar
2019-09-23 17:27         ` Dmitry Osipenko
2019-10-14  9:42       ` Viresh Kumar
2019-10-14 13:01         ` Dmitry Osipenko
2019-10-15 11:46       ` Viresh Kumar
2019-10-15 13:45         ` Dmitry Osipenko
2019-10-15 15:53         ` Rafael J. Wysocki
2019-10-15 21:50           ` Rafael J. Wysocki
2019-10-16  8:27             ` Viresh Kumar [this message]
2019-10-16  8:43               ` Rafael J. Wysocki
2019-07-04  7:36 ` [PATCH V6 6/7] cpufreq: intel_pstate: Reuse refresh_frequency_limits() Viresh Kumar
2019-07-04  7:36 ` [PATCH V6 7/7] cpufreq: Add QoS requests for userspace constraints Viresh Kumar
2019-07-05 10:51   ` [PATCH V7 " Viresh Kumar
2019-07-05 11:17     ` Rafael J. Wysocki

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=20191016082742.nttzuofes6uds4pu@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=digetx@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=pavel@ucw.cz \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=sfr@canb.auug.org.au \
    --cc=ulf.hansson@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.