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

Re: [Xen-devel] libxl: calculating free pages in libvirt

On Thu, 2013-06-06 at 15:53 +0200, Dario Faggioli wrote:
> Hi Jim,
> As I told you in Dublin, I'm looking into libvirt a bit, with the main
> purpose of implementing the NUMA interface for the libxl driver.
> While at it I noticed that libxlNodeGetFreeMemory() uses the value
> contained in phy_info.free_pages to check how many pages of free memory
> we have.
> However, starting from (Xen's git) commit bec8f17e, the number of free
> pages should be computed like this:
>  (phy_info.free_pages - phy_info.outstanding_pages)
> to take the memory claiming mechanism introduced by Oracle properly into
> account.

This only really matters if libvirt wants to coexist on a host with
toolstacks which use claim, otherwise outstanding pages will never be
non-zero. I don't know if coexistence is a goal or not.

>  You can see an example of that, for instance, looking at the
> output_physinfo() function in tools/libxl/xl_cmdimpl.c (in the Xen
> codebase, of course :-) ).
> Said commit is from last May, and the claim mechanism altogether --which
> includes adding the outstanding_pages field to the libxl_physinfo struct
> in libxl-- was introduced during the 4.3 development cycle.
> So, forgive the possibly dumb question, but what's the preferred way to
> fix this in libvirt, without breaking build with old libxl versions?
> (Provided this is something libvirt cares about, does it?)
> For other features added within this last dev cycle, libxl has a
> `#define LIBXL_HAVE_<foo>' (e.g., LIBXL_HAVE_DOMAIN_NODEAFFINITY), but I
> don't see one for this particular field... Konrad, Ian, am I missing it?

I don't think so, we seem to have forgotten.

> If no, should we add it?

Yes, I think that would be wise.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.