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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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.
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) >
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
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel