|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] freemem-slack and large memory environments
On Mon, 2 Mar 2015, Ian Campbell wrote:
> On Mon, 2015-03-02 at 15:19 +0000, Stefano Stabellini wrote:
> > On Mon, 2 Mar 2015, Ian Campbell wrote:
> > > On Fri, 2015-02-27 at 17:31 -0700, Mike Latimer wrote:
> > > > On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> > > > > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
> > > > > After adding 2048aeec, dom0's target is lowered by the required
> > > > > amount (e.g.
> > > > > 64GB), but as dom0 cannot balloon down fast enough,
> > > > > libxl_wait_for_memory_target returns -5, and the domain create fails
> > > > (wrong return code - libxl_wait_for_memory_target actually returns
> > > > -3)
> > > >
> > > > With libxl_wait_for_memory_target return code corrected (2048aeec),
> > > > debug
> > > > messages look like this:
> > > >
> > > > Parsing config from sles12pv
> > > > DBG: start freemem loop
> > > > DBG: free_memkb = 541976, need_memkb = 67651584 (rc=0)
> > > > DBG: dom0_curr_target = 2118976472, set_memory_target = -67109608
> > > > (rc=1)
> > > > DBG: wait_for_free_memory = 67651584 (rc=-5)
> > > > DBG: wait_for_memory_target (rc=-3)
> > > > failed to free memory for the domain
> > > >
> > > > After failing, dom0 continues to balloon down by the requested amount
> > > > (-67109608), so a subsequent startup attempt would work.
> > > >
> > > > My original fix (2563bca1) was intended to continue looping in freem
> > > > until dom0
> > > > ballooned down the requested amount. However, this really only worked
> > > > without
> > > > 2048aeec, as wait_for_memory_target was always returning 0. After
> > > > Stefano
> > > > pointed out this problem, commit 2563bca1 can still be useful - but
> > > > seems less
> > > > important as ballooning down dom0 is where the major delays are seen.
> > > >
> > > > The following messages show what was happening when
> > > > wait_for_memory_target was
> > > > always returning 0. I've narrowed it down to just the interesting
> > > > messages:
> > > >
> > > > DBG: free_memkb = 9794852, need_memkb = 67651584 (rc=0)
> > > > DBG: dom0_curr_target = 2118976464, set_memory_target = -67109596 (rc=1)
> > > > DBG: dom0_curr_target = 2051866868, set_memory_target = -57856732 (rc=1)
> > > > DBG: dom0_curr_target = 1994010136, set_memory_target = -50615004 (rc=1)
> > > > DBG: dom0_curr_target = 1943395132, set_memory_target = -43965148 (rc=1)
> > > > DBG: dom0_curr_target = 1899429984, set_memory_target = -37538524 (rc=1)
> > > > DBG: dom0_curr_target = 1861891460, set_memory_target = -31560412 (rc=1)
> > > > DBG: dom0_curr_target = 1830331048, set_memory_target = -25309916 (rc=1)
> > > > DBG: dom0_curr_target = 1805021132, set_memory_target = -19514076 (rc=1)
> > > > DBG: dom0_curr_target = 1785507056, set_memory_target = -13949660 (rc=1)
> > > > DBG: dom0_curr_target = 1771557396, set_memory_target = -8057564 (rc=1)
> > > > DBG: dom0_curr_target = 1763499832, set_memory_target = -1862364 (rc=1)
> > > >
> > > > The above situation is no longer relevant, but the overall dom0 target
> > > > problem
> > > > is still an issue. It now seems rather obvious (hopefully) that the 10
> > > > second
> > > > delay in wait_for_memory_target is not sufficient. Should that function
> > > > be
> > > > modified to monitor ongoing progress and continue waiting as long as
> > > > progress
> > > > is being made?
> > >
> > > You mean to push the logic currently in freemem to keep going so long as
> > > there is progress being made down into libxl_wait_for_memory_target?
> > > That seems like a good idea.
> >
> > "Continue as long as progress is being made" is not exactly the idea
> > behind the current implementation of freemem even if we do have a check
> > like
> >
> > if (free_memkb > free_memkb_prev) {
> >
> > at the end.
>
> ? "Continue as long as progress is being made" is exactly what
> 2563bca1154 "libxl: Wait for ballooning if free memory is increasing"
> was trying to implement, so it certainly was the idea behind the current
> implementation (it may well not have managed to implement the idea it
> was trying to).
I don't think so: pre-2563bca1154 it wasn't and 2563bca1154 doesn't
implement it properly. I think we should revert it.
> > See:
> >
> > http://marc.info/?l=xen-devel&m=142503529725529
> >
> > Specifically the current loop is not able to cope with Dom0 decreasing
> > its reservation but not reaching its target (because it is too slow or
> > because of other reasons).
>
> I'm not sure what you are saying here.
>
> Are you just agreeing with the suggestion in an oblique way?
I agree with the suggestion "continue as long as progress is being
made". I disagree that "continue as long as progress is being made" is
the current logic of freemem.
I don't have an opinion on whether that logic should be implemented in
freemem or libxl_wait_for_memory_target. The code below implements it in
libxl_wait_for_memory_target.
> > The following changes to freemem implements the aforementioned logic by
> > improving libxl_wait_for_memory_target to keep going as long as dom0 is
> > able to make progress and removing the useless free_memkb >
> > free_memkb_prev check.
> >
> >
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index b9d083a..ec98e00 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -5002,26 +5002,41 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx,
> > uint32_t domid, int wait_secs)
> > {
> > int rc = 0;
> > uint32_t target_memkb = 0;
> > + uint64_t current_memkb, prev_memkb;
> > libxl_dominfo info;
> >
> > + rc = libxl_get_memory_target(ctx, domid, &target_memkb);
> > + if (rc < 0)
> > + return rc;
> > +
> > libxl_dominfo_init(&info);
> > + prev_memkb = UINT64_MAX;
> >
> > do {
> > - wait_secs--;
> > sleep(1);
> >
> > - rc = libxl_get_memory_target(ctx, domid, &target_memkb);
> > - if (rc < 0)
> > - goto out;
> > -
> > libxl_dominfo_dispose(&info);
> > libxl_dominfo_init(&info);
> > rc = libxl_domain_info(ctx, &info, domid);
> > if (rc < 0)
> > goto out;
> > - } while (wait_secs > 0 && (info.current_memkb +
> > info.outstanding_memkb) > target_memkb);
> >
> > - if ((info.current_memkb + info.outstanding_memkb) <= target_memkb)
> > + current_memkb = info.current_memkb + info.outstanding_memkb;
> > +
> > + if (current_memkb > prev_memkb)
> > + {
> > + rc = ERROR_FAIL;
> > + goto out;
> > + }
> > + else if (current_memkb == prev_memkb)
> > + wait_secs--;
> > + /* if current_memkb < prev_memkb loop for free as progress has
> > + * been made */
> > +
> > + prev_memkb = current_memkb;
> > + } while (wait_secs > 0 && current_memkb > target_memkb);
> > +
> > + if (current_memkb <= target_memkb)
> > rc = 0;
> > else
> > rc = ERROR_FAIL;
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 53c16eb..17f61a8 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -2200,7 +2200,7 @@ static int freemem(uint32_t domid,
> > libxl_domain_build_info *b_info)
> > {
> > int rc, retries;
> > const int MAX_RETRIES = 3;
> > - uint32_t need_memkb, free_memkb, free_memkb_prev = 0;
> > + uint32_t need_memkb, free_memkb;
> >
> > if (!autoballoon)
> > return 0;
> > @@ -2228,22 +2228,14 @@ static int freemem(uint32_t domid,
> > libxl_domain_build_info *b_info)
> > else if (rc != ERROR_NOMEM)
> > return rc;
> >
> > - /* the memory target has been reached but the free memory is still
> > - * not enough: loop over again */
> > + /* wait until dom0 reaches its target, as long as we are making
> > + * progress */
> > rc = libxl_wait_for_memory_target(ctx, 0, 1);
> > if (rc < 0)
> > return rc;
> >
> > - /*
> > - * If the amount of free mem has increased on this iteration (i.e.
> > - * some progress has been made) then reset the retry counter.
> > - */
> > - if (free_memkb > free_memkb_prev) {
> > - retries = MAX_RETRIES;
> > - free_memkb_prev = free_memkb;
> > - } else {
> > - retries--;
> > - }
> > + /* dom0 target has been reached: loop again */
> > + retries--;
> > } while (retries > 0);
> >
> > return ERROR_NOMEM;
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |