linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dipankar Sarma <dipankar@in.ibm.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Brown, Len" <len.brown@intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Gautham R Shenoy <ego@in.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
	"Li, Shaohua" <shaohua.li@intel.com>, Ingo Molnar <mingo@elte.hu>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"Darrick J. Wong" <djwong@us.ibm.com>
Subject: Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
Date: Thu, 13 Aug 2009 01:27:53 +0530	[thread overview]
Message-ID: <20090812195753.GA14649@in.ibm.com> (raw)
In-Reply-To: <20090812115806.GK24339@elf.ucw.cz>

On Wed, Aug 12, 2009 at 01:58:06PM +0200, Pavel Machek wrote:
> Hi!
> 
> > May be having (to pick a number) 3 possible offline states for all
> > platforms with one for halt equivalent and one for deepest possible that
> > CPU can handle and one for deepest possible that platform likes for
> > C-states may make sense. Will keeps things simpler in terms of usage
> > expectations and possibly reduce the misuse oppurtubity?
> 
> Maybe just going to the deepest offline state automatically is the
> easiest option?

In a native system, I think we should the platform-specific code
export what makes sense. That may be just the lowest possible
state only. Or may be more than one.

In a virtualized system, we would want to do at least the following -

1. An offline configuration state where the hypervisor can
take the cpu back and allocate it to another VM.

2. A low-power state where the guest indicates it doesn't need the
CPU (and can be put in low power state) but doesn't want to give up 
its allocated cpu share. IOW, no visible configuration changes.

So, in any case we would probably want more than one states.

> cpu hotplug/unplug should be rare-enough operation that the latencies
> do not really matter, right?

As of now, from the platform perspective, I don't think low-power
state latencies matter in this code path. The only thing that might
have any relevance is electrical power-off technology and whether
there may be any h/w specific issues restricting its use. I don't know
that there will be any, but it may not be a good idea to prevent
platforms from requiring the use of multiple "offline" states.

Thanks
Dipankar

  parent reply	other threads:[~2009-08-12 19:57 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-05 14:25 [PATCH 0/3] cpu: idle state framework for offline CPUs Gautham R Shenoy
2009-08-05 14:25 ` [PATCH 1/3] cpu: Offline state Framework Gautham R Shenoy
2009-08-05 14:26 ` [PATCH 2/3] cpu: Implement cpu-offline-state callbacks for pSeries Gautham R Shenoy
2009-08-05 14:26 ` [PATCH 3/3] pSeries: cpu: Cede CPU during a deactivate-offline Gautham R Shenoy
2009-08-06  1:58 ` [PATCH 0/3] cpu: idle state framework for offline CPUs Shaohua Li
2009-08-06  4:33   ` Vaidyanathan Srinivasan
2009-08-06 15:03     ` Peter Zijlstra
2009-08-06 15:13       ` Peter Zijlstra
2009-08-09 12:08     ` Pavel Machek
2009-08-06 13:48   ` Gautham R Shenoy
2009-08-07  1:02     ` Shaohua Li
2009-08-09 12:08   ` Pavel Machek
2009-08-09 13:22     ` Rafael J. Wysocki
2009-08-10  2:00       ` Vaidyanathan Srinivasan
2009-08-10  8:19       ` Pavel Machek
2009-08-11  0:22         ` Pallipadi, Venkatesh
2009-08-11 17:53           ` Dipankar Sarma
2009-08-12 11:58           ` Pavel Machek
2009-08-12 12:05             ` Peter Zijlstra
2009-08-12 19:57             ` Dipankar Sarma [this message]
2009-08-13  0:45               ` Len Brown
2009-08-13  4:59                 ` Dipankar Sarma
2009-08-14 11:30                   ` Pavel Machek
2009-08-16 18:26                     ` Dipankar Sarma
2009-08-16 19:44                       ` Balbir Singh
2009-08-16 21:53                         ` Peter Zijlstra
2009-08-17  6:24                           ` Dipankar Sarma
2009-08-17  7:15                             ` Peter Zijlstra
2009-08-17  7:58                               ` Dipankar Sarma
2009-08-17 14:40                                 ` Dipankar Sarma

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=20090812195753.GA14649@in.ibm.com \
    --to=dipankar@in.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=djwong@us.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --cc=shaohua.li@intel.com \
    --cc=venkatesh.pallipadi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).