From: Mike Latimer <mlatimer@suse.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@eu.citrix.com, wei.liu2@citrix.com,
Ian Campbell <ian.campbell@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: freemem-slack and large memory environments
Date: Fri, 27 Feb 2015 17:31:32 -0700 [thread overview]
Message-ID: <1485105.OlVcWx0gpa@mlatimer1.dnsdhcp.provo.novell.com> (raw)
In-Reply-To: <8145398.E30EXKdkiW@mlatimer1.dnsdhcp.provo.novell.com>
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?
Sorry for the long discussion to get to this point. :(
-Mike
next prev parent reply other threads:[~2015-02-28 0:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 1:27 freemem-slack and large memory environments Mike Latimer
2015-02-10 21:34 ` Mike Latimer
2015-02-13 11:13 ` Wei Liu
2015-02-13 23:16 ` Mike Latimer
2015-02-18 14:10 ` Ian Campbell
2015-02-24 16:06 ` Stefano Stabellini
2015-02-24 16:54 ` Ian Campbell
2015-02-25 11:39 ` Stefano Stabellini
2015-02-25 12:00 ` Ian Campbell
2015-02-25 14:03 ` Ian Campbell
2015-02-25 14:09 ` Stefano Stabellini
2015-02-26 15:36 ` Mike Latimer
2015-02-26 15:57 ` Ian Campbell
2015-02-26 17:38 ` Mike Latimer
2015-02-26 17:47 ` Ian Campbell
2015-02-26 20:38 ` Mike Latimer
2015-02-27 10:17 ` Ian Campbell
2015-02-27 11:05 ` Stefano Stabellini
2015-02-26 17:53 ` Stefano Stabellini
2015-02-26 20:45 ` Mike Latimer
2015-02-26 23:30 ` Mike Latimer
2015-02-27 10:21 ` Ian Campbell
2015-02-27 10:52 ` Stefano Stabellini
2015-02-27 15:28 ` Mike Latimer
2015-02-27 18:29 ` Mike Latimer
2015-02-28 0:31 ` Mike Latimer [this message]
2015-03-02 10:12 ` Stefano Stabellini
2015-03-02 10:44 ` Jan Beulich
2015-03-02 12:13 ` Stefano Stabellini
2015-03-02 13:04 ` Jan Beulich
[not found] ` <54F46DDB020000780006505B@suse.com>
2015-03-02 22:49 ` Mike Latimer
2015-03-02 11:42 ` Ian Campbell
2015-03-02 15:19 ` Stefano Stabellini
2015-03-02 16:04 ` Ian Campbell
2015-03-02 16:15 ` Stefano Stabellini
2015-03-02 22:49 ` Mike Latimer
2015-03-03 10:02 ` Ian Campbell
2015-03-03 10:32 ` Stefano Stabellini
2015-03-03 10:40 ` Stefano Stabellini
2015-02-27 8:24 ` Jan Beulich
2015-02-27 10:52 ` Stefano Stabellini
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=1485105.OlVcWx0gpa@mlatimer1.dnsdhcp.provo.novell.com \
--to=mlatimer@suse.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--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.