Messages in this thread | | | Date | Mon, 17 Aug 2009 11:54:18 +0530 | From | Dipankar Sarma <> | Subject | Re: [PATCH 0/3] cpu: idle state framework for offline CPUs. |
| |
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 +----------->+------------+ > > +--+-----+ | hypervisor +-----> Reuse CPU > > | | | for something > > | | | else > > | | | (visible to users) > > | | | as resource changed > > | +----------- + > > V (needed, but can cede) > > +------------+ > > | hypervisor | Don't reuse CPU > > | | (CPU ceded) > > | | give back to OS > > +------------+ when needed. > > (Not visible to > > users as so resource > > binding changed) > > I still don't get it... _why_ should this be exposed in the guest > kernel? Why not let the hypervisor manage a guest's offline cpus in a > way it sees fit?
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 result in a VM resize in some hypervisor systems (like pseries) - it would be convenient to have a non-resize offline operation which lets the guest cede the cpu to hypervisor with the hint that the VM shouldn't be resized and the guest needs the guarantee to get the cpu back any time. The hypervisor can do whatever it wants with the ceded CPU including putting it in a low power state, but not change the physical cpu shares of the VM. The pseries hypervisor, for example, clearly distinguishes between the two - "rtas-stop-self" call to resize VM vs. H_CEDE hypercall with a hint. What I am suggesting is that we allow this with an extension to existing interfaces because it makes sense to allow sort of "hibernation" of the cpus without changing any configuration of the VMs.
Thanks Dipankar
| |