[Engine-devel] CPU Pinning @engine
Andrew Cathrow
acathrow at redhat.com
Thu May 17 14:38:56 UTC 2012
----- Original Message -----
> From: "Dor Laor" <dlaor at redhat.com>
> To: gkotton at redhat.com
> Cc: engine-devel at ovirt.org, "Eduardo Habkost" <ehabkost at redhat.com>, "Gleb Natapov" <gleb at redhat.com>
> Sent: Thursday, May 17, 2012 10:04:10 AM
> Subject: Re: [Engine-devel] CPU Pinning @engine
>
> On 05/17/2012 04:24 PM, Gary Kotton wrote:
> > On 05/17/2012 02:42 PM, Doron Fediuck wrote:
> >> Hi All,
> >> Currently the VDSM has a CPU pinning hook.
> >> We'd like to add better support of it into the engine itself.
> >> Here's a design draft to cover it:
> >> http://www.ovirt.org/wiki/Features/Design/cpu-pinning
> >>
> >> Please review and comment if needed.
> > Hi,
> > I have a number of comments:
> > 1. Will the user have any indication for the maximum amount of
> > vCPU's?
> > 2. What happens if a VM is already configured with the same CPU pin
> > info? Will this be shared?
Yes
> > 3. Would it possible to extend this to limit the MHz of CPU that
> > can be
> > allocated to a VM?
No, that's not supported today in KVM. In the future we should use cgroups to provide prioritization as part of the future SLA feature.
> > 5. If the VM has more than one core, will each core have to be
> > mapped?
yes
> > 6. "similar to the existing hook Shahar wrote" - can you please put
> > a
> > link the the hook that Shahar wrote. :) This will be helpful for
> > those
> > of us unfamiliar with it.
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks/pincpu;h=fd7a1a85912504d6b0cc8ae4e8123d71bf3c2741;hb=HEAD
But basically it's the same syntax as libvirt uses today.
> > 7. Why will live migration not be supported? What is the gap to
> > have
> > this type of support?
There's been disagreement here.
The argument against it is that if you have heterogeneous hardware then it might not work.
eg. If I pin on vCPU 10-11 on host A and and host B only has 8 CPUs ....
I'd argue that if an admin is doing the pinning then it's up to him to make sure he picks a sensible value
>
> +1 on the above.
>
> In addition, it should be nice to reveal the host cpu topology so the
> user will be able to match the virtual one.
> Getting the hyperthread topology is important factor as well.
>
> Numa is not mentioned at all. It should be highly desirable to expose
> the numa topology and add numa pinning using numactl.
> Since you're refactoring this code, adding options for the new numda
> daemon would be important too.
>
> Another important factor is the ability to pin not only the vcpu
> threads
> but also to pin 'service threads' in the host, potential to other
> physical cpus. Examples for such are the qemu io thread, vhost
> threads, etc.
>
> Regards,
> Dor
>
> > Thanks
> > Gary
> >> Thanks!
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
More information about the Devel
mailing list