On Fri, Aug 10, 2007 at 06:39:56AM -0400, Daniel Veillard wrote: > On Thu, Aug 09, 2007 at 11:13:00PM +0100, Daniel P. Berrange wrote: > > The Xen implementations of > > > > virDomainLookupByID > > virDomainLookupByUUID > > virDomainLookupByName > > virDomainGetOSType > > > > all have sub-optimal performance since they speak to XenD. The lookupXXX > > functions all basically require 3 pieces of info in the end (name,id,uuid). > > They each get given one piece & have to lookup the other piece. > > > > Every running domain has to have an entry in XenStore on /local/domain/N > > where 'N' is the id. Under this location there is always a 'name' field. > > So if we have the id we can efficiently get the name. I just realized that > > the getdomaininfo hypercall struct contains the uuid and id. So for the > > ByID and ByUUID calls we can get all the info we need with a hypercall and > > a read of xenstore. This is very efficient compared to hitting XenD. > > Great !!!! > > > As of Xen 3.1.0 hypervisor the flags in the getdomaininfo hypercall struct > > also mark whether the guest is HVM vs paraivrt, so we can also implement > > the GetOSType api with a single hypercall. > > Sounds good to though definitely not a bottleneck. > > > That just leaves the ByName impl. The only way I can think of doing this > > is to scan /local/domain/N in xenstore until we find it. I'm going to try > > this, but I'm not convinced it'll be any significantly than talking to XenD. > > I may be surprised though. > > Well if you have 100 guests, that may be slower, but in the average situation > of only a couple of guests, it could be a real speedup. The problem is that > a lot of domain may accumulate in xenstore /local/domain even if they are > not running, both implementation are likely to have completely different > behaviour based on the context. But from a cache locality perspective hitting > xenstore may scale way better under loaded machines, so it may prove faster > even on machines with hundreds of domains. Doing a fair performance comparison > may prove really hard. Actually the /local/domain/[ID] subtree is guarenteed to only contain running VMs. The /vm/[UUID] subtree is where cruft accumulates over time, so its safe to rely on info in the former, but not the latter Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list