On Mon, Jul 10, 2006 at 12:44:34PM -0400, Daniel Veillard wrote:
/** * virDomainGetVcpus: * @domain: pointer to domain object, or NULL for Domain0 * @info: pointer to an array of virVcpuInfo structures * @maxinfo: number of structures in info array * * Extract information about virtual CPUs of a domain, store it in info array. * * Returns the number of info filled in case of success, -1 in case of failure. */ int virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo)
Hum ... now the problem with that API entry point is that we 'burn' the maximum 256 processors in the ABI, i.e. if we ever need to go past 256 client and servers need to be recompiled. Maybe this is not a real problem in practice but that's annoying. Is there existing APIs doing this kind of things (in POSIX for example), and what hard limit did they use ? Maybe int virDomainGetVcpusNr(virDomainPtr domain, int nr, virVcpuInfoPtr info, int maxCPU); Where the maxCPU is defined by the client as the number of real CPU it defined in its virVcpuInfoPtr and then an iteration over the virtual CPU defined in the domain is possible too. Of course if the domain uses many virtual CPUs this would become expensive but somehow I don't see that being the common use, I would rather guess the domains created use a few CPUs even if instantiated on a very large machine. This
with the following structure (in libvirt.h): /** * virVcpuInfo: structure for information about a virtual CPU in a domain. */ #define VIR_MAX_CPUS 256
Hum, there is already NUMA machines with more than 256 processors, it's annoying to define an API limit when you know it is already breakable.
Yeah, if we define such a hard limit in the ABI, then I can pretty much guarentee this will come back to bite us. As Daniel says, there are already machines in existance with huge number of CPUS, so I can easily see us hitting that limit within a pretty short time period - particularly now that Xen has been ported to IA64 - cf HP Superdome machines with 128 physical CPUs - add in dual core & hyperthreading to that.... Regards, 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 -=|