From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Wei Liu <wei.liu2@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: xl mem-max error
Date: Wed, 12 Nov 2014 12:03:17 +0000 [thread overview]
Message-ID: <1415793797.29592.12.camel@citrix.com> (raw)
In-Reply-To: <5460DBEF.5000504@oracle.com>
On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
> OK. Let me try my best:
>
> >>> I'm confused by the description of what's going on, in particular the
> >>> mixing of mem-max commands and target xenstore nodes (since the former
> >>> doesn't really affect the latter).
> >>>
> >>> How was the domain started (memory= and maxmem=).
>
> xl create with 'memory = 700', no maxmem been set. I think it means maxmem = memory for this case.
>
> >>> What were static-max and target at the point?
>
> /local/domain/3/memory/static-max = "716800"
> /local/domain/3/memory/target = "716801"
>
> >>> What did they change to when xl mem-max was issued?
>
> When I issue 'xl mem-max <domid> 700', static-max and target in xenstore will not change, but it will cause the command to fail.
>
> Because: "libxl: error: libxl.c:4549:libxl_domain_setmaxmem: memory_static_max must be greater than or or equal to memory_dynamic_max"
>
> >>> What did you expect them to change to instead?
>
> I expect I can set the maxmem to the same value I initially set (700).
OK, thanks, got it. I think the use of xl mem-max is a bit of a
red-herring, the issue here is that static-max < target at start of day.
I suspect there is either a rounding error somewhere or because of
LIBXL_MAXMEM_CONSTANT being inconsistently applied to the two values
somewhere along the line.
We had been planning[0] to remove this early in the 4.5 cycle, but as
ever it never floated to the top of anyone's list. For 4.5 we should
probably look at applying this fudge more consistently.
Ian.
[0] http://bugs.xenproject.org/xen/bug/23
next prev parent reply other threads:[~2014-11-12 12:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 22:17 xl mem-max error Zhigang Wang
2014-11-07 11:05 ` Wei Liu
2014-11-07 14:21 ` Zhigang Wang
2014-11-10 12:37 ` Wei Liu
2014-11-10 12:44 ` Ian Campbell
2014-11-10 15:29 ` Zhigang Wang
2014-11-10 15:30 ` Ian Campbell
2014-11-10 15:38 ` Zhigang Wang
2014-11-12 12:03 ` Ian Campbell [this message]
2014-11-17 20:03 ` Zhigang Wang
2014-11-18 9:26 ` Ian Campbell
2014-11-18 20:57 ` [PATCH] set pv guest default video_memkb to 0 Zhigang Wang
2014-11-19 21:08 ` Konrad Rzeszutek Wilk
2014-11-19 21:24 ` Wei Liu
2014-11-20 15:29 ` Ian Campbell
2014-11-20 15:48 ` Wei Liu
2014-11-20 19:44 ` Konrad Rzeszutek Wilk
2014-11-28 12:12 ` Ian Campbell
2014-11-20 15:29 ` Ian Campbell
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=1415793797.29592.12.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
--cc=zhigang.x.wang@oracle.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.