Question about host CPU usage/allocation by KVM

Question about host CPU usage/allocation by KVM

[Alexander Lyakas]

Greetings everybody,

Can anybody please point me to code/documentation regarding the
following questions I have:

- What does it actually mean using "-smp N" option, in terms of CPU
sharing between the host and the guest?
- How are guest CPUs mapped to host CPUs (if at all)?
- Is it possible to hard-allocate one or more CPUs to a particular
guest, preventing the host from using them?
- Is it possible to limit guest usage of host CPUs?
(- Do my questions make sense?)

I am running stock ubuntu-natty 2.6.38-8, with KVM 0.14.0.

Thanks!

Re: Question about host CPU usage/allocation by KVM

[Avi Kivity]

On 04/18/2012 12:54 AM, Alexander Lyakas wrote:
> Greetings everybody,
>
> Can anybody please point me to code/documentation regarding the
> following questions I have:
>
> - What does it actually mean using "-smp N" option, in terms of CPU
> sharing between the host and the guest?

What does cpu sharing mean?

> - How are guest CPUs mapped to host CPUs (if at all)?

The host scheduler allocates guest vcpus to host cpus.  This allocation
changes with demand from other processes (or guests) on the host.

> - Is it possible to hard-allocate one or more CPUs to a particular
> guest, preventing the host from using them?

Look up 'cpusets'.

> - Is it possible to limit guest usage of host CPUs?

Look up 'cgroups cpu controller'.

-- 
error compiling committee.c: too many arguments to function

Re: Question about host CPU usage/allocation by KVM

[Stuart Yoder]

On Tue, Apr 17, 2012 at 4:54 PM, Alexander Lyakas
<alex.bolshoy@gmail.com> wrote:
> Greetings everybody,
>
> Can anybody please point me to code/documentation regarding the
> following questions I have:
>
> - What does it actually mean using "-smp N" option, in terms of CPU
> sharing between the host and the guest?
> - How are guest CPUs mapped to host CPUs (if at all)?

Each guest CPU (vcpu) corresponds to a QEMU thread.
You can see the thread ids in QEMU with "info cpus" in the
QEMU monitor.

Since a vcpu is a thread you can apply standard Linux
mechanisms to managing those threads-- CPU affinity, etc.

Stuart

Re: Question about host CPU usage/allocation by KVM

[Alexander Lyakas]

Thanks Avi and Stuart!

On Wed, Apr 18, 2012 at 8:24 PM, Stuart Yoder <b08248@gmail.com> wrote:
> On Tue, Apr 17, 2012 at 4:54 PM, Alexander Lyakas
> <alex.bolshoy@gmail.com> wrote:
>> Greetings everybody,
>>
>> Can anybody please point me to code/documentation regarding the
>> following questions I have:
>>
>> - What does it actually mean using "-smp N" option, in terms of CPU
>> sharing between the host and the guest?
>> - How are guest CPUs mapped to host CPUs (if at all)?
>
> Each guest CPU (vcpu) corresponds to a QEMU thread.
> You can see the thread ids in QEMU with "info cpus" in the
> QEMU monitor.
>
> Since a vcpu is a thread you can apply standard Linux
> mechanisms to managing those threads-- CPU affinity, etc.
>
> Stuart

Re: Question about host CPU usage/allocation by KVM

[Alexander Lyakas]

Hi Stuart,
I have been doing some experiments, and I noticed that there are
additional QEMU threads, besides the ones reported by "info cpus"
command. In particular, the main QEMU thread (the one whose LWP is the
same as its PID), also consumes significant CPU time. Is this
expected?

Alex.


On Wed, Apr 18, 2012 at 8:24 PM, Stuart Yoder <b08248@gmail.com> wrote:
> On Tue, Apr 17, 2012 at 4:54 PM, Alexander Lyakas
> <alex.bolshoy@gmail.com> wrote:
>> Greetings everybody,
>>
>> Can anybody please point me to code/documentation regarding the
>> following questions I have:
>>
>> - What does it actually mean using "-smp N" option, in terms of CPU
>> sharing between the host and the guest?
>> - How are guest CPUs mapped to host CPUs (if at all)?
>
> Each guest CPU (vcpu) corresponds to a QEMU thread.
> You can see the thread ids in QEMU with "info cpus" in the
> QEMU monitor.
>
> Since a vcpu is a thread you can apply standard Linux
> mechanisms to managing those threads-- CPU affinity, etc.
>
> Stuart

Re: Question about host CPU usage/allocation by KVM

[Brian Jackson]

On Thu, 19 Apr 2012 13:01:54 -0500, Alexander Lyakas  
<alex.bolshoy@gmail.com> wrote:

> Hi Stuart,
> I have been doing some experiments, and I noticed that there are
> additional QEMU threads, besides the ones reported by "info cpus"
> command. In particular, the main QEMU thread (the one whose LWP is the
> same as its PID), also consumes significant CPU time. Is this
> expected?

The extra threads are for various things. It can be for the vnc server if  
you are using it. Threads are used to mimic aio in certain situations.  
Etc. The main thread also does a lot of the device emulation work  
(console, network, serial, block, etc.)


>
> Alex.
>
>
> On Wed, Apr 18, 2012 at 8:24 PM, Stuart Yoder <b08248@gmail.com> wrote:
>> On Tue, Apr 17, 2012 at 4:54 PM, Alexander Lyakas
>> <alex.bolshoy@gmail.com> wrote:
>>> Greetings everybody,
>>>
>>> Can anybody please point me to code/documentation regarding the
>>> following questions I have:
>>>
>>> - What does it actually mean using "-smp N" option, in terms of CPU
>>> sharing between the host and the guest?
>>> - How are guest CPUs mapped to host CPUs (if at all)?
>>
>> Each guest CPU (vcpu) corresponds to a QEMU thread.
>> You can see the thread ids in QEMU with "info cpus" in the
>> QEMU monitor.
>>
>> Since a vcpu is a thread you can apply standard Linux
>> mechanisms to managing those threads-- CPU affinity, etc.
>>
>> Stuart
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Question about host CPU usage/allocation by KVM

[Shergill, Gurinder]

| -----Original Message-----
| From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
| Behalf Of Brian Jackson
| Sent: Friday, April 20, 2012 8:01 AM
| To: Stuart Yoder; Alexander Lyakas
| Cc: kvm@vger.kernel.org
| Subject: Re: Question about host CPU usage/allocation by KVM
| 
| On Thu, 19 Apr 2012 13:01:54 -0500, Alexander Lyakas
| <alex.bolshoy@gmail.com> wrote:
| 
| > Hi Stuart,
| > I have been doing some experiments, and I noticed that there are
| > additional QEMU threads, besides the ones reported by "info cpus"
| > command. In particular, the main QEMU thread (the one whose LWP is the
| > same as its PID), also consumes significant CPU time. Is this
| > expected?
| 
| The extra threads are for various things. It can be for the vnc server if
| you are using it. Threads are used to mimic aio in certain situations.
| Etc. The main thread also does a lot of the device emulation work
| (console, network, serial, block, etc.)

Is there some way to know what they are for ? or how many can get created ?

I noticed that the number of threads go from ~4 to ~70 if I do some I/O inside the guest.

Sunny

| 
| 
| >
| > Alex.
| >
| >
| > On Wed, Apr 18, 2012 at 8:24 PM, Stuart Yoder <b08248@gmail.com> wrote:
| >> On Tue, Apr 17, 2012 at 4:54 PM, Alexander Lyakas
| >> <alex.bolshoy@gmail.com> wrote:
| >>> Greetings everybody,
| >>>
| >>> Can anybody please point me to code/documentation regarding the
| >>> following questions I have:
| >>>
| >>> - What does it actually mean using "-smp N" option, in terms of CPU
| >>> sharing between the host and the guest?
| >>> - How are guest CPUs mapped to host CPUs (if at all)?
| >>
| >> Each guest CPU (vcpu) corresponds to a QEMU thread.
| >> You can see the thread ids in QEMU with "info cpus" in the QEMU
| >> monitor.
| >>
| >> Since a vcpu is a thread you can apply standard Linux mechanisms to
| >> managing those threads-- CPU affinity, etc.
| >>
| >> Stuart
| > --
| > To unsubscribe from this list: send the line "unsubscribe kvm" in the
| > body of a message to majordomo@vger.kernel.org More majordomo info at
| > http://vger.kernel.org/majordomo-info.html
| --
| To unsubscribe from this list: send the line "unsubscribe kvm" in the body
| of a message to majordomo@vger.kernel.org More majordomo info at
| http://vger.kernel.org/majordomo-info.html