[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090816182629.GA31027@in.ibm.com>
Date: Sun, 16 Aug 2009 23:56:29 +0530
From: Dipankar Sarma <dipankar@...ibm.com>
To: Pavel Machek <pavel@....cz>
Cc: Len Brown <lenb@...nel.org>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"Li, Shaohua" <shaohua.li@...el.com>,
Gautham R Shenoy <ego@...ibm.com>,
Joel Schopp <jschopp@...tin.ibm.com>,
"Brown, Len" <len.brown@...el.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Balbir Singh <balbir@...ibm.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Ingo Molnar <mingo@...e.hu>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
"Darrick J. Wong" <djwong@...ibm.com>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
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), you will actually create a configuration
> > change in the VM that is visible to other systems management tools
> > which may not be what the system administrator wanted. Ideally,
> > we would like to distinguish between these two states.
> >
> > Hope that suffices as an example.
>
> So... you have something like "physically pulling out hotplug cpu" on
> powerpc.
If any system can do physical unplug, then it should do "offline"
with configuration changes reflected in the hypervisor and
other system configuration software.
> But maybe it is useful to take already offline cpus (from linux side),
> and make that visible to hypervisor, too.
>
> So maybe something like "echo 1 > /sys/devices/system/cpu/cpu1/unplug"
> would be more useful for hypervisor case?
On pseries, we do an RTAS call ("stop-cpu") which effectively permantently
de-allocates it from the VM hands over the control to hypervisor. The
hypervisors may do whatever it wants including allocating it to
another VM. Once gone, the original VM may not get it back depending
on the situation.
The point I am making is that we may not always want to *release*
the CPU to hypervisor and induce a configuration change. That needs
to be reflected by extending the existing user interface - hence
the proposal for - /sys/devices/system/cpu/cpu<#>/state and
/sys/devices/system/cpu/cpu<#>/available_states. It allows
ceding to hypervisor without de-allocating. It is a minor
extension of the existing interface keeping backwards compatibility
and platforms can allow what make sense.
Thanks
Dipankar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists