Re: libxl: calculating free pages in libvirt

* Re: libxl: calculating free pages in libvirt
       [not found] <1370526793.18519.266.camel@Solace>
@ 2013-06-06 13:59 ` Ian Campbell
  2013-06-06 14:25   ` Dario Faggioli
       [not found]   ` <1370528712.18519.278.camel@Solace>
  2013-06-06 18:31 ` Konrad Rzeszutek Wilk
  1 sibling, 2 replies; 6+ messages in thread
From: Ian Campbell @ 2013-06-06 13:59 UTC (permalink / raw)
  To: Dario Faggioli; +Cc: libvir-list, Jim Fehlig, Konrad Rzeszutek Wilk, xen-devel

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.

Ian.

^ permalink raw reply	[flat|nested] 6+ messages in thread