All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Steve Muckle <steve.muckle@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Juri Lelli <Juri.Lelli@arm.com>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs
Date: Thu, 19 May 2016 01:33:09 +0200	[thread overview]
Message-ID: <CAJZ5v0iWfc=cNaCVuQ9QLK0FMLy1i5zEVcZSutOAK=+1OxaRtg@mail.gmail.com> (raw)
In-Reply-To: <1462828814-32530-4-git-send-email-smuckle@linaro.org>

On Mon, May 9, 2016 at 11:20 PM, Steve Muckle <steve.muckle@linaro.org> wrote:
> Without calling the cpufreq hook for a remote wakeup it is possible
> for such a wakeup to go unnoticed by cpufreq on the target CPU for up
> to a full tick. This can occur if the target CPU is running a
> CPU-bound task and preemption does not occur. If preemption does occur
> then the scheduler is expected to run soon on the target CPU anyway so
> invoking the cpufreq hook on the remote wakeup is not required.
>
> In order to avoid unnecessary interprocessor communication in the
> governor for the preemption case, the existing hook (which happens
> before preemption is decided) is only called when the target CPU
> is within the current CPU's cpufreq policy. A new hook is added in
> check_preempt_curr() to handle events outside the current CPU's
> cpufreq policy where preemption does not happen.
>
> Some governors may opt to not receive remote CPU callbacks. This
> behavior is possible by providing NULL as the new policy_cpus
> parameter to cpufreq_add_update_util_hook(). Callbacks will only be
> issued in this case when the target CPU and the current CPU are the
> same. Otherwise policy_cpus is used to determine what is a local
> vs. remote callback.

I don't really like the extra complexity added by this patch.

It makes the code look fragile at some places and it only really
matters for schedutil and for the fast switch case in there.

Overall, it looks like a premature optimization to me.

  reply	other threads:[~2016-05-18 23:33 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 21:20 [PATCH 0/5] cpufreq: schedutil: improve latency of response Steve Muckle
2016-05-09 21:20 ` [PATCH 1/5] sched: cpufreq: add cpu to update_util_data Steve Muckle
2016-05-18 23:13   ` Rafael J. Wysocki
2016-05-09 21:20 ` [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs Steve Muckle
2016-05-18 23:24   ` Rafael J. Wysocki
2016-05-19 18:40     ` Steve Muckle
2016-05-19 20:55       ` Rafael J. Wysocki
2016-05-19 22:59         ` Steve Muckle
2016-05-19 23:14           ` Rafael J. Wysocki
2016-05-09 21:20 ` [PATCH 3/5] sched: cpufreq: call cpufreq hook from " Steve Muckle
2016-05-18 23:33   ` Rafael J. Wysocki [this message]
2016-05-19 12:00     ` Rafael J. Wysocki
2016-05-19 19:19       ` Steve Muckle
2016-05-19 21:06         ` Rafael J. Wysocki
2016-05-19 23:04           ` Steve Muckle
2016-05-21 19:46             ` Steve Muckle
2016-06-01 20:09               ` Steve Muckle
2016-05-09 21:20 ` [PATCH 4/5] cpufreq: schedutil: map raw required frequency to CPU-supported frequency Steve Muckle
2016-05-18 23:37   ` Rafael J. Wysocki
2016-05-19 19:35     ` Steve Muckle
2016-05-19 21:07       ` Rafael J. Wysocki
2016-05-09 21:20 ` [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged Steve Muckle
2016-05-18 23:44   ` Rafael J. Wysocki
2016-05-19 19:46     ` Steve Muckle
2016-05-19 21:15       ` Rafael J. Wysocki
2016-05-19 23:34         ` Steve Muckle
2016-05-20  0:24           ` Rafael J. Wysocki
2016-05-20  0:37             ` Rafael J. Wysocki
2016-05-20  0:40               ` Steve Muckle
2016-05-20  0:46                 ` Rafael J. Wysocki
2016-05-20 11:39                   ` Rafael J. Wysocki
2016-05-20 11:54                     ` Rafael J. Wysocki
2016-05-20 11:59                       ` Rafael J. Wysocki
2016-05-20  0:37             ` Steve Muckle
2016-05-20  0:55               ` 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='CAJZ5v0iWfc=cNaCVuQ9QLK0FMLy1i5zEVcZSutOAK=+1OxaRtg@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=Juri.Lelli@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=steve.muckle@linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@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.