All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	tglx@linutronix.de, linux-pm@vger.kernel.org
Subject: Re: [PATCHSET] workqueue: reimplement CPU hotplug to keep idle workers
Date: Sat, 21 Jul 2012 12:12:13 +0530	[thread overview]
Message-ID: <CAMQu2gy0OtMaYZzPwJqO+VbVbd_y-cCE8sXowrhmqWWxzimu=g@mail.gmail.com> (raw)
In-Reply-To: <201207202144.05154.rjw@sisk.pl>

Rafael,

On Sat, Jul 21, 2012 at 1:14 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday, July 20, 2012, Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Jul 20, 2012 at 08:22:30PM +0200, Peter Zijlstra wrote:
>> > I really think people who use hotplug at high frequencies are on drugs
>> > and doing it wrong.
>>
>> I don't know.  It does make some sense.  It's not like we have any
>> other mechanism to keep some processors completely quiesient, which
>> could make a noticeable difference from powersaving POV compared to
>> mostly idle.  Rafael, can you please chime in and explain how / where
>> / how freqeuntly / etc CPU hotplug is used for powersaving?
>
> Well, there are use cases I'm not really familiar with.
>
> Pretty much the only use case I'm sufficiently familiar with is
> suspend/hibernate where we unplug all of the nonboot CPUs at one point.
>
> The other use cases, which I don't really think are entirely valid,
> are on some ARM platforms where CPUs are unplugged instead of being put into
> C-states or equivalent (because we don't have a good mechanism for handling
> multiprocessor C-states; there's a set of patches for that waiting for
> the merge window in the Len's tree).  I'm hoping to get rid of those
> use cases in future entirely.
>
Not sure if you are talking about couple idle series waiting in Len's tree for
the merge.

That series actually trying add infrastructure for the hardwares
where CPU's need co-ordination which is needed on few ARM hardwares
to get into deeper CPU cluster C-states. It is indeed true that without
that approach, cpu-hotplug was used to overcome the ordering issue
I guess Exynos, Tegra and OMAP are the few ARM architectures I
know who has been using the couple cpuidle infrastructure.

Regards
Santosh
Regards
Santosh

  parent reply	other threads:[~2012-07-21  6:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-17 17:12 [PATCHSET] workqueue: reimplement CPU hotplug to keep idle workers Tejun Heo
2012-07-17 17:12 ` [PATCH 1/9] workqueue: perform cpu down operations from low priority cpu_notifier() Tejun Heo
2012-07-20 21:52   ` Paul E. McKenney
2012-07-20 21:58     ` Tejun Heo
2012-07-21 21:36       ` Paul E. McKenney
2012-07-22 16:43         ` [PATCH] workqueue: fix spurious CPU locality WARN from process_one_work() Tejun Heo
2012-07-22 21:23           ` Paul E. McKenney
2012-07-17 17:12 ` [PATCH 2/9] workqueue: drop CPU_DYING notifier operation Tejun Heo
2012-07-17 17:12 ` [PATCH 3/9] workqueue: ROGUE workers are UNBOUND workers Tejun Heo
2012-07-17 17:12 ` [PATCH 4/9] workqueue: use mutex for global_cwq manager exclusion Tejun Heo
2012-07-17 17:12 ` [PATCH 5/9] workqueue: drop @bind from create_worker() Tejun Heo
2012-07-17 17:12 ` [PATCH 6/9] workqueue: reimplement CPU online rebinding to handle idle workers Tejun Heo
2012-07-17 17:12 ` [PATCH 7/9] workqueue: don't butcher idle workers on an offline CPU Tejun Heo
2012-07-17 17:12 ` [PATCH 8/9] workqueue: remove CPU offline trustee Tejun Heo
2012-07-17 17:12 ` [PATCH 9/9] workqueue: simplify CPU hotplug code Tejun Heo
2012-07-17 18:43 ` [PATCHSET] workqueue: reimplement CPU hotplug to keep idle workers Rafael J. Wysocki
2012-07-17 19:40   ` Tejun Heo
2012-07-20 15:48 ` Peter Zijlstra
2012-07-20 17:02   ` Tejun Heo
2012-07-20 17:21     ` Peter Zijlstra
2012-07-20 17:50       ` Tejun Heo
2012-07-20 18:22         ` Peter Zijlstra
2012-07-20 18:34           ` Tejun Heo
2012-07-20 19:44             ` Rafael J. Wysocki
2012-07-20 19:41               ` Tejun Heo
2012-07-21  6:42               ` Shilimkar, Santosh [this message]
2012-07-23  8:38               ` Peter De Schrijver
2012-07-20 16:39 ` Peter Zijlstra
2012-07-20 16:52   ` Tejun Heo
2012-07-20 17:01     ` Peter Zijlstra
2012-07-20 17:08       ` Tejun Heo
2012-07-20 17:19         ` Peter Zijlstra
2012-07-20 17:43           ` Tejun Heo

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='CAMQu2gy0OtMaYZzPwJqO+VbVbd_y-cCE8sXowrhmqWWxzimu=g@mail.gmail.com' \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.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.