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