linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM list <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Subject: Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()
Date: Tue, 15 Mar 2016 13:10:59 +0700	[thread overview]
Message-ID: <20160315061059.GB13831@vireshk-mac-ubuntu> (raw)
In-Reply-To: <5379622.iJjZa2C2Nq@vostro.rjw.lan>

On 12-03-16, 03:05, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> cpufreq_resume() attempts to resync the current frequency with
> policy->cur for the first online CPU, but first it does that after
> restarting governors for all active policies (which means that this
> is racy with respect to whatever the governors do) and second it

Why? Its doing the update withing policy->rwsem ..

> already is too late for that when cpufreq_resume() is called (that
> happens after invoking ->resume callbacks for all devices in the
> system).
> 
> Also it doesn't make sense to do that for one CPU only in any case,
> because the other CPUs in the system need not share the policy with
> it and their policy->cur may be out of sync as well in principle.

Its done just for the boot CPU, because that's the only CPU that goes to
suspend. All other CPUs are disabled/enabled and so the policies are
reinitialized for policy->cur as well.

I think, its still important to get things in sync, as some bootloader may
change the frequency to something else during resume.

And our code may not be safe for the case, the current frequency of the CPU
isn't part of the freq-table of the policy.

-- 
viresh

  reply	other threads:[~2016-03-15  6:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-12  2:05 [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume() Rafael J. Wysocki
2016-03-15  6:10 ` Viresh Kumar [this message]
2016-03-15 12:11   ` Rafael J. Wysocki
2016-03-16  0:51     ` Rafael J. Wysocki
2016-03-16  4:52       ` Viresh Kumar
2016-03-16 12:29         ` Rafael J. Wysocki
2016-03-17  6:44           ` Viresh Kumar
2016-03-16  4:47     ` Viresh Kumar
2016-03-16 13:12       ` Rafael J. Wysocki
2016-03-17  6:30         ` Viresh Kumar

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=20160315061059.GB13831@vireshk-mac-ubuntu \
    --to=viresh.kumar@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=srinivas.pandruvada@linux.intel.com \
    /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).