Re: Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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  -=| 


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]