All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Len Brown <lenb@kernel.org>
Cc: Shaohua Li <shaohua.li@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"menage@google.com" <menage@google.com>,
	Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Subject: Re: [PATCH]cpuset: add new API to change cpuset top group's cpus
Date: Wed, 20 May 2009 00:36:41 +0200	[thread overview]
Message-ID: <1242772601.26820.527.camel@twins> (raw)
In-Reply-To: <alpine.LFD.2.00.0905191429440.29241@localhost.localdomain>

On Tue, 2009-05-19 at 15:01 -0400, Len Brown wrote:
> > ... the point is, we
> > don't need a new interface to force a cpu idle. Hotplug does that.
> >
> > Furthermore, we should not want anything outside of that, either the cpu
> > is there available for work, or its not -- halfway measures don't make
> > sense.
> > 
> > Furthermore, we already have power aware scheduling which tries to
> > aggregate idle time on cpu/core/packages so as to maximize the idle time
> > power savings. Use it there.
> 
> Some context...

<snip default story of thermal overcommit>

> > > > Besides, a hot removed cpu will do a dead loop halt, which isn't power saving
> > > > efficient. To make hot removed cpu enters deep C-state is in whish list for a
> > > > long time, but still not available. The acpi_processor_idle is a module, and
> > > > cpuidle governor potentially can't handle offline cpu.
> > > 
> > > Then fix that hot-unplug idle loop. I agree that the hlt thing is silly,
> > > and I've no idea why its still there, seems like a much better candidate
> > > for your efforts than this.
> 
> CONFIG_HOTPLUG_CPU has been problematic in the past.
> It does more than what we need here, so we thought
> a lighter-weight and lower-latency method that simply
> didn't schedule to the idled cpu would suffice.

> We are fixing the hotplug-unplug idle loop, but there
> turns out to be some issues with it related to idle
> processors with interrupts disabled that don't actually
> get down into the deep C-states we request:-(
> 
> So this is why you see a patch for a "halfway measure",
> it does what is necessary, and does nothing more.

Its broken, its ill-defined and its not going to happen.

Ripping cpus out of the top cpuset might upset the cpuset configuration
and has no regards for any realtime processes. And I must take back my
earlier suggestion, hotplug is a bad solution too.

There's just too much user policy (cpuset configuration) to upset.

The IBM folks are working on a scheduler based solution, please talk to
them.



  reply	other threads:[~2009-05-19 22:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-19  7:39 [PATCH]cpuset: add new API to change cpuset top group's cpus Shaohua Li
2009-05-19  8:40 ` Peter Zijlstra
2009-05-19  8:48   ` Shaohua Li
2009-05-19  8:56     ` Peter Zijlstra
2009-05-19  9:06       ` Shaohua Li
2009-05-19  9:31         ` Peter Zijlstra
2009-05-19 10:38       ` Peter Zijlstra
2009-05-19 13:37         ` Vaidyanathan Srinivasan
2009-05-28  2:34           ` Len Brown
2009-05-28  7:44             ` Vaidyanathan Srinivasan
2009-05-19 19:01         ` Len Brown
2009-05-19 22:36           ` Peter Zijlstra [this message]
2009-05-20 11:58             ` Andi Kleen
2009-05-20 12:17               ` Peter Zijlstra
2009-05-20 13:13                 ` Andi Kleen
2009-05-20 13:41                   ` Peter Zijlstra
2009-05-20 14:45                     ` Andi Kleen
2009-05-20 17:36                     ` Vaidyanathan Srinivasan
2009-05-21  1:22                       ` Shaohua Li
2009-05-21  3:20                         ` Vaidyanathan Srinivasan
2009-05-20 17:21           ` Vaidyanathan Srinivasan
2009-05-19 11:27   ` Andi Kleen
2009-05-19 12:01     ` Peter Zijlstra
2009-05-19 19:55 ` Paul Menage
2009-05-19 19:55   ` Paul Menage

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=1242772601.26820.527.camel@twins \
    --to=peterz@infradead.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=shaohua.li@intel.com \
    --cc=svaidy@linux.vnet.ibm.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 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.