[libvirt] [PATCH 00/17] Supports for hypervisor-pin and hypervisor-bandwidth
This series is a merge of 1) "Support hypervisor-threads-pin in vcpupin" (https://www.redhat.com/archives/libvir-list/2012-July/msg01361.html) 2) "support to set cpu bandwidth for hypervisor threads" (https://www.redhat.com/archives/libvir-list/2012-June/msg01161.html) to make life easier because of the two share some patches. Patches 1-12 are from 1), patches 13-17 are from 2). Changes: 1. rebase to the latest git tree(removal of qemuReportError, split of virsh.c) 2. some typo fixes 3. make it pass syntax-check Hu Tao (2): limit cpu bandwidth only for vcpus update doc about hypervisor_period/hypervisor_quota Tang Chen (9): Enable cpuset cgroup and synchronous vcpupin info to cgroup. Support hypervisorpin xml parse. Introduce qemuSetupCgroupHypervisorPin and synchronize hypervisorpin info to cgroup. Add qemuProcessSetHypervisorAffinites and set hypervisor threads affinities Introduce virDomainHypervisorPinAdd and virDomainHypervisorPinDel functions Introduce virDomainPinHypervisorFlags and virDomainGetHypervisorPinInfo functions. Introduce qemudDomainPinHypervisorFlags and qemudDomainGetHypervisorPinInfo in qemu driver. Introduce remoteDomainPinHypervisorFlags and remoteDomainGetHypervisorPinInfo functions in remote driver. Improve vcpupin to support hypervisorpin dynamically. Wen Congyang (6): Introduce the function virCgroupForHypervisor Introduce the function virCgroupMoveTask create a new cgroup and move all hypervisor threads to the new cgroup Update XML Schema for new entries qemu: Implement hypervisor's period and quota tunable XML configuration and parsing qemu: Implement hypervisor_period and hypervisor_quota's modification daemon/remote.c | 103 + docs/schemas/domaincommon.rng | 17 + include/libvirt/libvirt.h.in| 26 ++ src/conf/domain_conf.c | 189 - src/conf/domain_conf.h |9 + src/driver.h| 13 +- src/libvirt.c | 147 +++ src/libvirt_private.syms|7 + src/libvirt_public.syms |2 + src/qemu/qemu_cgroup.c | 193 -- src/qemu/qemu_cgroup.h |5 + src/qemu/qemu_driver.c | 465 +++ src/qemu/qemu_process.c | 60 ++- src/remote/remote_driver.c | 102 + src/remote/remote_protocol.x| 23 +- src/remote_protocol-structs | 24 ++ src/util/cgroup.c | 188 - src/util/cgroup.h | 15 + tests/qemuxml2argvdata/qemuxml2argv-cputune.xml |1 + tests/vcpupin |6 +- tools/virsh-domain.c| 147 --- tools/virsh.pod | 23 +- 22 files changed, 1594 insertions(+), 171 deletions(-) -- 1.7.10.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/17] Supports for hypervisor-pin and hypervisor-bandwidth
On 08/03/2012 12:36 AM, Hu Tao wrote: > This series is a merge of > > 1) "Support hypervisor-threads-pin in vcpupin" > (https://www.redhat.com/archives/libvir-list/2012-July/msg01361.html) > 2) "support to set cpu bandwidth for hypervisor threads" > (https://www.redhat.com/archives/libvir-list/2012-June/msg01161.html) > > to make life easier because of the two share some patches. > > Patches 1-12 are from 1), patches 13-17 are from 2). > > Changes: > 1. rebase to the latest git tree(removal of qemuReportError, split of > virsh.c) > 2. some typo fixes > 3. make it pass syntax-check Thanks for reposting. I do intend to review this series next, and this refresher is a big help. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/17] Supports for hypervisor-pin and hypervisor-bandwidth
On Fri, Aug 03, 2012 at 02:36:02PM +0800, Hu Tao wrote: > This series is a merge of > > 1) "Support hypervisor-threads-pin in vcpupin" > (https://www.redhat.com/archives/libvir-list/2012-July/msg01361.html) > 2) "support to set cpu bandwidth for hypervisor threads" > (https://www.redhat.com/archives/libvir-list/2012-June/msg01161.html) > > to make life easier because of the two share some patches. This series is really focusing on pinning threads associated with the element, rather than the hypervisor. The hypervisor is a separate entity that is shared. So I'm thinking that this entire patch series could replace 'hypervisor' with 'emulator' everywhere. Any one has agree or disagree ? Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/17] Supports for hypervisor-pin and hypervisor-bandwidth
On 08/07/2012 09:47 AM, Daniel P. Berrange wrote: > On Fri, Aug 03, 2012 at 02:36:02PM +0800, Hu Tao wrote: >> This series is a merge of >> >> 1) "Support hypervisor-threads-pin in vcpupin" >> (https://www.redhat.com/archives/libvir-list/2012-July/msg01361.html) >> 2) "support to set cpu bandwidth for hypervisor threads" >> (https://www.redhat.com/archives/libvir-list/2012-June/msg01161.html) >> >> to make life easier because of the two share some patches. > > This series is really focusing on pinning threads associated > with the element, rather than the hypervisor. The > hypervisor is a separate entity that is shared. > > So I'm thinking that this entire patch series could replace > 'hypervisor' with 'emulator' everywhere. Any one has agree > or disagree ? I definitely agree - when I hear 'hypervisor', I think 'qemu:///system', which is the technology used to run multiple guests, but when I hear 'emulator', I think of a subset of a domain, namely the specific qemu pid_t running a given guest. Also, we're not pinning all of the hypervisor's threads, but just the threads that are associated with emulation but not a specific vcpu. That is, marking up your comment in 1/17: cgroup mount point +--libvirt<= setting up a namespace (*) +--qemu<= hypervisor level +--domain name <= domain level +--vcpu0 <= vcpu level ... +--vcpuN +--"hypervisor" <= emulator so a domain really is made up of an 'emulator' and 'vcpu' threads, and a 'hypervisor' contains domains, rather than making up a portion of a domain. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/17] Supports for hypervisor-pin and hypervisor-bandwidth
On Tue, Aug 07, 2012 at 10:13:19AM -0600, Eric Blake wrote: > On 08/07/2012 09:47 AM, Daniel P. Berrange wrote: > > On Fri, Aug 03, 2012 at 02:36:02PM +0800, Hu Tao wrote: > >> This series is a merge of > >> > >> 1) "Support hypervisor-threads-pin in vcpupin" > >> (https://www.redhat.com/archives/libvir-list/2012-July/msg01361.html) > >> 2) "support to set cpu bandwidth for hypervisor threads" > >> (https://www.redhat.com/archives/libvir-list/2012-June/msg01161.html) > >> > >> to make life easier because of the two share some patches. > > > > This series is really focusing on pinning threads associated > > with the element, rather than the hypervisor. The > > hypervisor is a separate entity that is shared. > > > > So I'm thinking that this entire patch series could replace > > 'hypervisor' with 'emulator' everywhere. Any one has agree > > or disagree ? > > I definitely agree - when I hear 'hypervisor', I think 'qemu:///system', > which is the technology used to run multiple guests, but when I hear > 'emulator', I think of a subset of a domain, namely the specific qemu > pid_t running a given guest. Also, we're not pinning all of the > hypervisor's threads, but just the threads that are associated with > emulation but not a specific vcpu. > > That is, marking up your comment in 1/17: > > cgroup mount point > +--libvirt<= setting up a namespace (*) >+--qemu<= hypervisor level > +--domain name <= domain level > +--vcpu0 <= vcpu level > ... > +--vcpuN > +--"hypervisor" <= emulator > > so a domain really is made up of an 'emulator' and 'vcpu' threads, and a > 'hypervisor' contains domains, rather than making up a portion of a domain. Also note that LXC has an emulator "/usr/libexec/libvirt_lxc" for which all these new APIs apply, but the term 'hypervisor' is meaningless for container based virt. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/17] Supports for hypervisor-pin and hypervisor-bandwidth
On Tue, Aug 07, 2012 at 06:35:32PM +0100, Daniel P. Berrange wrote: > On Tue, Aug 07, 2012 at 10:13:19AM -0600, Eric Blake wrote: > > On 08/07/2012 09:47 AM, Daniel P. Berrange wrote: > > > On Fri, Aug 03, 2012 at 02:36:02PM +0800, Hu Tao wrote: > > >> This series is a merge of > > >> > > >> 1) "Support hypervisor-threads-pin in vcpupin" > > >> > > >> (https://www.redhat.com/archives/libvir-list/2012-July/msg01361.html) > > >> 2) "support to set cpu bandwidth for hypervisor threads" > > >> > > >> (https://www.redhat.com/archives/libvir-list/2012-June/msg01161.html) > > >> > > >> to make life easier because of the two share some patches. > > > > > > This series is really focusing on pinning threads associated > > > with the element, rather than the hypervisor. The > > > hypervisor is a separate entity that is shared. > > > > > > So I'm thinking that this entire patch series could replace > > > 'hypervisor' with 'emulator' everywhere. Any one has agree > > > or disagree ? > > > > I definitely agree - when I hear 'hypervisor', I think 'qemu:///system', > > which is the technology used to run multiple guests, but when I hear > > 'emulator', I think of a subset of a domain, namely the specific qemu > > pid_t running a given guest. Also, we're not pinning all of the > > hypervisor's threads, but just the threads that are associated with > > emulation but not a specific vcpu. > > > > That is, marking up your comment in 1/17: > > > > cgroup mount point > > +--libvirt<= setting up a namespace (*) > >+--qemu<= hypervisor level > > +--domain name <= domain level > > +--vcpu0 <= vcpu level > > ... > > +--vcpuN > > +--"hypervisor" <= emulator > > > > so a domain really is made up of an 'emulator' and 'vcpu' threads, and a > > 'hypervisor' contains domains, rather than making up a portion of a domain. > > Also note that LXC has an emulator "/usr/libexec/libvirt_lxc" for > which all these new APIs apply, but the term 'hypervisor' is > meaningless for container based virt. Thank you for your advice on the naming. I'll change hypervisor into emulator all through the series. -- Thanks, Hu Tao -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
