On Sun, Aug 16, 2009 at 11:53:22PM +0200, Peter Zijlstra wrote:
On Mon, 2009-08-17 at 01:14 +0530, Balbir Singh wrote:
Agreed, I've tried to come with a little ASCII art to depict your
scenairos graphically
++ don't need (offline)
| OS
On Mon, 2009-08-17 at 11:54 +0530, Dipankar Sarma wrote:
On Sun, Aug 16, 2009 at 11:53:22PM +0200, Peter Zijlstra wrote:
On Mon, 2009-08-17 at 01:14 +0530, Balbir Singh wrote:
Agreed, I've tried to come with a little ASCII art to depict your
scenairos graphically
On Mon, Aug 17, 2009 at 09:15:57AM +0200, Peter Zijlstra wrote:
On Mon, 2009-08-17 at 11:54 +0530, Dipankar Sarma wrote:
For most parts, we do. The guest kernel doesn't manage the offline
CPU state. That is typically done by the hypervisor. However, offline
operation as defined now always
On Mon, Aug 17, 2009 at 01:28:15PM +0530, Dipankar Sarma wrote:
On Mon, Aug 17, 2009 at 09:15:57AM +0200, Peter Zijlstra wrote:
On Mon, 2009-08-17 at 11:54 +0530, Dipankar Sarma wrote:
For most parts, we do. The guest kernel doesn't manage the offline
CPU state. That is typically done by
* Dipankar Sarma dipan...@in.ibm.com [2009-08-16 23:56:29]:
On Fri, Aug 14, 2009 at 01:30:21PM +0200, Pavel Machek wrote:
It depends on the hypervisor implementation. On pseries (powerpc)
hypervisor, for example, they are different. By offlining a vcpu
(and in turn shutting a cpu),
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.
How are #1 and
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
On Wed, 2009-08-12 at 13:58 +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
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
On Thu, 13 Aug 2009, Dipankar Sarma wrote:
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
On Wed, Aug 12, 2009 at 08:45:18PM -0400, Len Brown wrote:
On Thu, 13 Aug 2009, Dipankar Sarma wrote:
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.
For x86, it is 1
On Mon, Aug 10, 2009 at 05:22:17PM -0700, Pallipadi, Venkatesh wrote:
Also, I don't think using just the ACPI/BIOS supplied states in _CST is
right thing to do for offline. _CST is meant for C-state and BIOS may
not include some C-state in _CST if the system manufacturer thinks that
the
On Sun 2009-08-09 15:22:02, Rafael J. Wysocki wrote:
On Sunday 09 August 2009, Pavel Machek wrote:
Hi!
Also, approaches such as [1] can make use of this
extended infrastructure instead of putting the CPU to an arbitrary
C-state
when it is offlined, thereby providing the
On Mon, 2009-08-10 at 01:19 -0700, Pavel Machek wrote:
On Sun 2009-08-09 15:22:02, Rafael J. Wysocki wrote:
On Sunday 09 August 2009, Pavel Machek wrote:
Hi!
Also, approaches such as [1] can make use of this
extended infrastructure instead of putting the CPU to an arbitrary
Hi!
Also, approaches such as [1] can make use of this
extended infrastructure instead of putting the CPU to an arbitrary C-state
when it is offlined, thereby providing the system administrator a rope to
hang
himself with should he feel the need to do so.
I didn't see the reason
Hi!
Also, approaches such as [1] can make use of this
extended infrastructure instead of putting the CPU to an arbitrary C-state
when it is offlined, thereby providing the system administrator a rope to
hang
himself with should he feel the need to do so.
I didn't see the reason why
On Sunday 09 August 2009, Pavel Machek wrote:
Hi!
Also, approaches such as [1] can make use of this
extended infrastructure instead of putting the CPU to an arbitrary C-state
when it is offlined, thereby providing the system administrator a rope to
hang
himself with should he
* Rafael J. Wysocki r...@sisk.pl [2009-08-09 15:22:02]:
On Sunday 09 August 2009, Pavel Machek wrote:
Hi!
Also, approaches such as [1] can make use of this
extended infrastructure instead of putting the CPU to an arbitrary
C-state
when it is offlined, thereby providing the
Hi Shaohua,
On Thu, Aug 06, 2009 at 09:58:55AM +0800, Shaohua Li wrote:
Hi,
On Wed, Aug 05, 2009 at 10:25:53PM +0800, Gautham R Shenoy wrote:
In this patch-series, we propose to extend the CPU-Hotplug infrastructure
and allow the system administrator to choose the desired state the CPU
On Thu, 2009-08-06 at 17:03 +0200, Peter Zijlstra wrote:
On Thu, 2009-08-06 at 10:03 +0530, Vaidyanathan Srinivasan wrote:
This was the
main objection to Venki's deepest sleep state for offline cpus patch.
Well, my main objection was that is was a single raw function pointer
without any
On Thu, 2009-08-06 at 10:03 +0530, Vaidyanathan Srinivasan wrote:
This was the
main objection to Venki's deepest sleep state for offline cpus patch.
Well, my main objection was that is was a single raw function pointer
without any management layer around it.
We have the exact same mess with
On Thu, Aug 06, 2009 at 09:48:44PM +0800, Gautham R Shenoy wrote:
Hi Shaohua,
On Thu, Aug 06, 2009 at 09:58:55AM +0800, Shaohua Li wrote:
Hi,
On Wed, Aug 05, 2009 at 10:25:53PM +0800, Gautham R Shenoy wrote:
In this patch-series, we propose to extend the CPU-Hotplug infrastructure
Hi,
RFC not for inclusion
When we perform a CPU-Offline operation today, we do not put the CPU
into the most energy efficient state. On x86, it loops in hlt as opposed to
going to one of the low-power C-states. On pSeries, we call rtas_stop_self()
and hand over the vCPU back to the
* Shaohua Li shaohua...@intel.com [2009-08-06 09:58:55]:
Hi,
On Wed, Aug 05, 2009 at 10:25:53PM +0800, Gautham R Shenoy wrote:
In this patch-series, we propose to extend the CPU-Hotplug infrastructure
and allow the system administrator to choose the desired state the CPU
should
go to
Hi,
On Wed, Aug 05, 2009 at 10:25:53PM +0800, Gautham R Shenoy wrote:
In this patch-series, we propose to extend the CPU-Hotplug infrastructure
and allow the system administrator to choose the desired state the CPU should
go to when it is offlined. We think this approach addresses the concerns
25 matches
Mail list logo
