All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: libvir-list@redhat.com, Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Jim Fehlig <jfehlig@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: libxl: calculating free pages in libvirt
Date: Thu, 6 Jun 2013 14:31:37 -0400	[thread overview]
Message-ID: <20130606183137.GA21465@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <1370526793.18519.266.camel@Solace>

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

  parent reply	other threads:[~2013-06-06 18:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1370526793.18519.266.camel@Solace>
2013-06-06 13:59 ` libxl: calculating free pages in libvirt Ian Campbell
2013-06-06 14:25   ` Dario Faggioli
     [not found]   ` <1370528712.18519.278.camel@Solace>
2013-06-06 21:50     ` Jim Fehlig
     [not found]     ` <51B10433.7050806@suse.com>
2013-06-06 22:54       ` Dario Faggioli
2013-06-06 18:31 ` Konrad Rzeszutek Wilk [this message]
2013-06-06 13:53 Dario Faggioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130606183137.GA21465@konrad-lan.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=jfehlig@suse.com \
    --cc=libvir-list@redhat.com \
    --cc=raistlin@linux.it \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.