All of lore.kernel.org
 help / color / mirror / Atom feed
From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Mike Turquette <mturquette@linaro.org>,
	peterz@infradead.org, mingo@kernel.org
Cc: linux-kernel@vger.kernel.org, Morten.Rasmussen@arm.com,
	kamalesh@linux.vnet.ibm.com, riel@redhat.com, efault@gmx.de,
	nicolas.pitre@linaro.org, linaro-kernel@lists.linaro.org,
	daniel.lezcano@linaro.org, dietmar.eggemann@arm.com,
	pjt@google.com, bsegall@google.com, vincent.guittot@linaro.org,
	patches@linaro.org, tuukka.tikkanen@linaro.org,
	amit.kucheria@linaro.org,
	Shilpa Bhat <shilpa.bhat@linux.vnet.ibm.com>
Subject: Re: [PATCH RFC 6/7] sched: cfs: cpu frequency scaling based on task placement
Date: Thu, 27 Nov 2014 16:16:55 +0530	[thread overview]
Message-ID: <5477011F.5020509@linux.vnet.ibm.com> (raw)
In-Reply-To: <1413958051-7103-7-git-send-email-mturquette@linaro.org>

On 10/22/2014 11:37 AM, Mike Turquette wrote:
> {en,de}queue_task_fair are updated to track which cpus will have changed
> utilization values as function of task queueing. The affected cpus are
> passed on to arch_eval_cpu_freq for further machine-specific processing
> based on a selectable policy.
> 
> arch_scale_cpu_freq is called from run_rebalance_domains as a way to
> kick off the scaling process (via wake_up_process), so as to prevent
> re-entering the {en,de}queue code.
> 
> All of the call sites in this patch are up for discussion. Does it make
> sense to track which cpus have updated statistics in enqueue_fair_task?
> I chose this because I wanted to gather statistics for all cpus affected
> in the event CONFIG_FAIR_GROUP_SCHED is enabled. As agreed at LPC14 the
> next version of this patch will focus on the simpler case of not using
> scheduler cgroups, which should remove a good chunk of this code,
> including the cpumask stuff.
> 
> Also discussed at LPC14 is that fact that load_balance is a very
> interesting place to do this as frequency can be considered in concert
> with task placement. Please put forth any ideas on a sensible way to do
> this.

I believe load balancing would be the right place to evaluate the
frequency at which CPUs must run. find_busiest_group() is already
iterating through all the CPUs and calculating the load on them. So this
information is readily available and that which remains to be seen is
which of the CPUs in the group have their load > some_threshold and
queue a kthread on that cpu to scale its frequency, while the current
cpu continues with its load balancing.

There is another positive I see in evaluating cpu frequency in load
balancing. The frequency at which load balancing is run is already
optimized for scalability. One of the factors that is considered is if
any sibling cpus has carried out load balancing in the recent past, the
current cpu defers doing the same. This means it is naturally ensured
that only one cpu in the power domain takes care of frequency scaling
each time and there is no need of explicit synchronization between the
policy cpus to do this.

Regards
Preeti U Murthy


  parent reply	other threads:[~2014-11-27 10:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22  6:07 [PATCH RFC 0/7] scheduler-driven cpu frequency scaling Mike Turquette
2014-10-22  6:07 ` [PATCH RFC 1/7] sched: Make energy awareness a sched feature Mike Turquette
2014-10-22  6:07 ` [PATCH RFC 2/7] sched: cfs: declare capacity_of in sched.h Mike Turquette
2014-10-22  6:07 ` [PATCH RFC 3/7] sched: fair: add usage_util_of helper Mike Turquette
2014-10-22  6:07 ` [PATCH RFC 4/7] cpufreq: add per-governor private data Mike Turquette
2014-10-22  6:26   ` Viresh Kumar
2014-10-22  6:35     ` Mike Turquette
2014-10-22  6:07 ` [PATCH RFC 5/7] sched: cfs: cpu frequency scaling arch functions Mike Turquette
2014-10-22 20:06   ` Rik van Riel
2014-10-22 23:20     ` Mike Turquette
2014-10-23  1:42       ` Rik van Riel
2014-10-23  2:12         ` Mike Galbraith
2014-10-23  2:42           ` Rik van Riel
2014-10-22  6:07 ` [PATCH RFC 6/7] sched: cfs: cpu frequency scaling based on task placement Mike Turquette
2014-10-23  4:03   ` Preeti U Murthy
2014-10-27 15:55   ` Peter Zijlstra
2014-10-27 17:42   ` Dietmar Eggemann
2014-11-27 10:46   ` Preeti U Murthy [this message]
2014-10-22  6:07 ` [PATCH RFC 7/7] sched: energy_model: simple cpu frequency scaling policy Mike Turquette
2014-10-27 19:43   ` Dietmar Eggemann
2014-10-28 14:27   ` Peter Zijlstra

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=5477011F.5020509@linux.vnet.ibm.com \
    --to=preeti@linux.vnet.ibm.com \
    --cc=Morten.Rasmussen@arm.com \
    --cc=amit.kucheria@linaro.org \
    --cc=bsegall@google.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=efault@gmx.de \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mturquette@linaro.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=patches@linaro.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=riel@redhat.com \
    --cc=shilpa.bhat@linux.vnet.ibm.com \
    --cc=tuukka.tikkanen@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.