mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steve Muckle <smuckle@google.com>
To: Joel Fernandes <joelaf@google.com>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Cc: Srinivas Pandruvada" <srinivas.pandruvada@linux.intel.com>,
	"Cc: Len Brown" <lenb@kernel.org>,
	"Cc: Juri Lelli" <juri.lelli@arm.com>,
	"Cc: Patrick Bellasi" <patrick.bellasi@arm.com>,
	"Cc: Brendan Jackman" <brendan.jackman@arm.com>,
	"Cc: Chris Redpath" <Chris.Redpath@arm.com>,
	"Cc: Atish Patra" <atish.patra@oracle.com>,
	"Cc: Dietmar Eggemann" <dietmar.eggemann@arm.com>,
	"Cc: Vincent Guittot" <vincent.guittot@linaro.org>,
	"Cc: Morten Ramussen" <morten.rasmussen@arm.com>,
	"Cc: Frederic Weisbecker" <fweisbec@gmail.com>,
	"Cc: Thomas Gleixner" <tglx@linutronix.de>,
	"Cc: EAS Dev" <eas-dev@lists.linaro.org>,
	"Cc: Android Kernel" <kernel-team@android.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle
Date: Wed, 1 Nov 2017 12:35:37 -0700	[thread overview]
Message-ID: <6ed7d641-4fa2-77e1-9294-64d51193c786@google.com> (raw)
In-Reply-To: <CAJWu+opNBs2u2FbXBKGtYeW2ipR7o-NUCOA95zh3xo-pqmd5mw@mail.gmail.com>

On 10/30/2017 12:02 PM, Joel Fernandes wrote:
>> Also, this more looks like a policy decision. Will it be better to
>> put that directly into schedutil? Like this:
>>
>>          if (cpu_idle())
>>                  "Don't change the freq";
>>
>> Will something like that work?
> 
> I thought about this and I think it wont work very well. In the
> dequeue path we're still running the task being dequeued so the CPU is
> not yet idle. What is needed here IMO is a notion that the CPU is
> possibly about to idle and we can get predict that from the dequeue
> path of the CFS class.
> 
> Also just looking at whether the CPU is currently idle or not in the
> governor doesn't help to differentiate between say the dequeue path /
> tick path. Both of which can occur when the CPU is not idle.
> 
> Any thoughts about this?

Also if it really is the case that this bit of policy is universally 
desirable, I'd think it is better to do this in the scheduler and avoid 
a needless trip through a fn pointer out to schedutil for performance 
reasons.

  reply	other threads:[~2017-11-01 19:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-28  9:59 [PATCH RFC 0/5] sched and cpufreq fixes/cleanups Joel Fernandes
2017-10-28  9:59 ` [PATCH RFC 1/5] Revert "sched/fair: Drop always true parameter of update_cfs_rq_load_avg()" Joel Fernandes
2017-10-28  9:59 ` [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle Joel Fernandes
2017-10-30 12:07   ` Viresh Kumar
2017-10-30 19:02     ` Joel Fernandes
2017-11-01 19:35       ` Steve Muckle [this message]
2017-11-04  5:44         ` Joel Fernandes
2017-11-06  8:00           ` Vincent Guittot
2017-11-06  9:29             ` Uladzislau Rezki
2017-11-08  5:11             ` Joel Fernandes
2017-10-28  9:59 ` [PATCH RFC 3/5] cpufreq: schedutil: Use idle_calls counter of the remote CPU Joel Fernandes
2017-10-30  9:18   ` Viresh Kumar
2017-10-28  9:59 ` [PATCH RFC 4/5] sched/fair: Correct obsolete comment about cpufreq_update_util Joel Fernandes
2017-10-30  9:22   ` Viresh Kumar
2017-10-30 19:16     ` Joel Fernandes
2017-10-28  9:59 ` [PATCH RFC 5/5] sched/fair: remove impossible condition from find_idlest_group_cpu Joel Fernandes
2017-10-30 15:41   ` Brendan Jackman
2017-10-30 16:00   ` Vincent Guittot
2017-10-30 16:19     ` Joel Fernandes
2017-10-30 16:26       ` Vincent Guittot

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=6ed7d641-4fa2-77e1-9294-64d51193c786@google.com \
    --to=smuckle@google.com \
    --cc=Chris.Redpath@arm.com \
    --cc=atish.patra@oracle.com \
    --cc=brendan.jackman@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=eas-dev@lists.linaro.org \
    --cc=fweisbec@gmail.com \
    --cc=joelaf@google.com \
    --cc=juri.lelli@arm.com \
    --cc=kernel-team@android.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome