[Libvir] Start NUMA work

[Daniel P. Berrange]

On Tue, Sep 11, 2007 at 11:39:07AM -0400, Daniel Veillard wrote:
> On Tue, Sep 11, 2007 at 04:28:00PM +0100, Richard W.M. Jones wrote:
> > Daniel Veillard wrote:
> > >  Okay enclosed is a first patch to add the new entry point for getting
> > >the available memeory in the NUMA cells:
> > >
> > >/**
> > > * virNodeGetCellFreeMemory:
> > > * @conn: pointer to the hypervisor connection
> > > * @freeMems: pointer to the array of unsigned long
> > > * @nbCells: number of entries available in freeMems
> > > *
> > > * This call allows to ask the amount of free memory in each NUMA cell.
> > > * The @freeMems array must be allocated by the caller and will be filled
> > > * with the amounts of free memory in kilobytes for each cell starting
> > > * from cell #0 and up to @nbCells -1 or the number of cell in the Node
> > > * (which can be found using virNodeGetInfo() see the nodes entry in the
> > > * structure).
> > > *
> > > * Returns the number of entries filled in freeMems, or -1 in case of 
> > > error.
> > > */
> > >
> > >int 
> > >virNodeGetCellsFreeMemory(virConnectPtr conn, unsigned long *freeMems,
> > >                          int nbCells)
> > 
> > So you're using "unsigned long" here to mean 32 bits on 32 bit archs, 
> > and 64 bits on 64 bit archs?
> > 
> > A purely 32 bit freeMem will allow up to 4095 GB of RAM per cell.  But 
> > in reality up to 2047 GB of RAM because mappings in other languages will 
> > probably be signed.
> > 
> > High-end users are already decking out PCs with 128 GB of RAM.  If they 
> > double the RAM every year, we'll hit this limit in 4 years[1].  So is it 
> > worth using an explicit 64 bit quantity here, or using another base (MB 
> > instead of KB for example)?  Or do we just think that all such vast 
> > machines will be 64 bit?
> 
>   Well we already use unsigned long in KB for memory quantities in
> libvirt, I just reused that, I doubt we will see more than 64GB for
> 32bits CPU ever, that's already stretching the limits

Just because we mistakenly used 32-bit for various memory quantites elswhere
doesn't been we should propagate this mistake for new APIs. As John points
out, on Solaris they use a 32-bit userspace even on a 64-bit host. The same
can be true of Linux - you can run 32-bit dom0 on 64-bit hypervisor - indeed
I believe XenEnterprise does this for their Dom0. If we think a quantity
may need 64-bits at some point, then we should use long long. I think it
is worth using long long in this case.

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