Re: libxl: calculating free pages in libvirt

Re: libxl: calculating free pages in libvirt

[Ian Campbell]

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.

Re: libxl: calculating free pages in libvirt

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1706 bytes --]

On gio, 2013-06-06 at 14:59 +0100, Ian Campbell wrote:
> 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.
> 
Sure, all this is important only if having it is
important/interesting... Jim?

> > 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.
> 
Ok, sending a patch (for libxl) then.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: libxl: calculating free pages in libvirt

[Jim Fehlig]

Dario Faggioli wrote:
> On gio, 2013-06-06 at 14:59 +0100, Ian Campbell wrote:
>   
>> 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.
>>
>>     
> Sure, all this is important only if having it is
> important/interesting... Jim?
>   

It would be preferable if libvirt and xl coexisted nicely.  No need for
them to inter-operate (e.g. start a vm with libvirt then manage it with
xl), but managing some with xl and others with libvirt should be a goal,
I think :-/.  If nothing else, it seems useful for troubleshooting.  I
wouldn't want to advise a user to try xl when things are failing for
them with libvirt, only to find that afterwards their libvirt no longer
worked at all.

Regards,
Jim

Re: libxl: calculating free pages in libvirt

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1547 bytes --]

On gio, 2013-06-06 at 15:50 -0600, Jim Fehlig wrote:
> Dario Faggioli wrote:
> > On gio, 2013-06-06 at 14:59 +0100, Ian Campbell wrote:
> >> 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.
> >>
> >>     
> > Sure, all this is important only if having it is
> > important/interesting... Jim?
> >   
> 
> It would be preferable if libvirt and xl coexisted nicely.  No need for
> them to inter-operate (e.g. start a vm with libvirt then manage it with
> xl), but managing some with xl and others with libvirt should be a goal,
> I think :-/.  If nothing else, it seems useful for troubleshooting.  I
> wouldn't want to advise a user to try xl when things are failing for
> them with libvirt, only to find that afterwards their libvirt no longer
> worked at all.
> 
Mmm... I'm not entirely sure I understand what you mean by this, but
anyway, I just submitted a patch to libxl adding the symbol necessary to
determine whether that field is present or not.

If it gets accepted, I can then patch libvirt to use it, within the
proper #ifdef...#endif block, of course.

Thanks everyone and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: libxl: calculating free pages in libvirt

[Konrad Rzeszutek Wilk]

On Thu, Jun 06, 2013 at 03:53:13PM +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. 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?
> If no, should we add it?

I think we missed it. I remember thinking about it, but I can't recall
what I didn't submit. It certainly should be added.

And I think that would fix the build of old libxl against new libvirt.
Or vice-versa (if libxl supported the claim operation).
> 
> Thanks and Regards,
> Dario
> 
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 

libxl: calculating free pages in libvirt

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1663 bytes --]

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. 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?
If no, should we add it?

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel