All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jim Fehlig <jfehlig@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	mlatimer@suse.com
Subject: Re: [PATCH 0/4] fix freemem loop
Date: Fri, 6 Mar 2015 09:59:05 +0000	[thread overview]
Message-ID: <1425635945.14353.30.camel@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1503060946060.15212@kaball.uk.xensource.com>

On Fri, 2015-03-06 at 09:48 +0000, Stefano Stabellini wrote:
> On Thu, 5 Mar 2015, Ian Campbell wrote:
> > On Tue, 2015-03-03 at 11:08 +0000, Stefano Stabellini wrote:
> > > Hi all,
> > > 
> > > this patch series fixes the freemem loop on machines with very large
> > > amount of memory, where the current wait time is not enough.
> > > 
> > > In order to be able to handle arbitrarly large amount of ram, we
> > > implement in libxl_wait_for_memory_target a policy of waiting until dom0
> > > is making progress.
> > 
> > What is the impact of the libxl API change made here on other callers,
> > in particular libvirt?
> > 
> > If it is expected that existing callers should continue to work as
> > before (perhaps with a redundant call etc) then please state this in the
> > relevant commit message(s).
> 
> The change to libxl_wait_for_memory_target will cause the function to
> wait as long as dom0 is ballooning down by any amount of memory in a 2
> seconds time frame. Therefore callers might end up waiting for longer
> than before, specifically longer than the amount of seconds they pass to
> libxl_wait_for_memory_target.
> 
> I'll add this message to the relevant commit.

Thanks. It might be worth waiting for Jim to say what the impact on new
libvirt (i.e. updated to take advantage of the fixed interface) built
against old libxl would be -- since we may want to include a #define
LIBXL_HAVE_SOMETHING in the resend.

> 
> 
> > >   The patch series also reverts "libxl: Wait for
> > > ballooning if free memory is increasing", that is not actually
> > > implemented correctly.
> > > 
> > > 
> > > Stefano Stabellini (4):
> > >       Revert "libxl: Wait for ballooning if free memory is increasing"
> > >       libxl_wait_for_memory_target: wait as long as dom0 is making progress
> > >       freemem: remove call to libxl_wait_for_free_memory
> > >       libxl_wait_for_memory_target: wait for 2 sec at a time
> > > 
> > >  tools/libxl/libxl.c      |   31 +++++++++++++++++++++++--------
> > >  tools/libxl/xl_cmdimpl.c |   29 ++++++-----------------------
> > >  2 files changed, 29 insertions(+), 31 deletions(-)
> > > 
> > > Cheers,
> > > 
> > > Stefano
> > 
> > 

      reply	other threads:[~2015-03-06  9:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03 11:08 [PATCH 0/4] fix freemem loop Stefano Stabellini
2015-03-03 11:08 ` [PATCH 1/4] Revert "libxl: Wait for ballooning if free memory is increasing" Stefano Stabellini
2015-03-03 11:08 ` [PATCH 2/4] libxl_wait_for_memory_target: wait as long as dom0 is making progress Stefano Stabellini
2015-03-06 18:10   ` Jim Fehlig
2015-03-03 11:08 ` [PATCH 3/4] freemem: remove call to libxl_wait_for_free_memory Stefano Stabellini
2015-03-03 11:08 ` [PATCH 4/4] libxl_wait_for_memory_target: wait for 2 sec at a time Stefano Stabellini
2015-03-03 21:54 ` [PATCH 0/4] fix freemem loop Mike Latimer
2015-03-04 23:55   ` Mike Latimer
2015-03-05 17:49 ` Ian Campbell
2015-03-06  4:08   ` Mike Latimer
2015-03-06  9:46     ` Ian Campbell
2015-03-06  9:52       ` Stefano Stabellini
2015-03-06 10:13         ` Ian Campbell
2015-03-06 10:22           ` Stefano Stabellini
2015-03-06 10:45             ` Ian Campbell
2015-03-06 17:58             ` Jim Fehlig
2015-03-06  9:48   ` Stefano Stabellini
2015-03-06  9:59     ` Ian Campbell [this message]

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=1425635945.14353.30.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=jfehlig@suse.com \
    --cc=mlatimer@suse.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /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.