Re: [Xen-devel] xl mem-max error

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-11-17 at 15:03 -0500, Zhigang Wang wrote:
> On 11/12/2014 07:03 AM, Ian Campbell wrote:
> > 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
> 
> Here is more info (correct me if something wrong):
> 
> 1. libxl_types.idl:
> 
>     ("video_memkb", MemKB)
> 
>     MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT", json_gen_fn = 
> "libxl__uint64_gen_json")
> 
>   libxl.h: #define LIBXL_MEMKB_DEFAULT ~0ULL
> 
>   So video_memkb = -1 by default.
> 
> 2. For hvm, we will set it into: 0, 16M, 8M according to hvm.vga.kind 
> (libxl_create.c)
> 
> 3. For pv guest, we will use default (-1).
> 
> 4. When we calculate static-max and target memory:
> 
>     ents[0] = "memory/static-max";
>     ents[1] = GCSPRINTF("%"PRId64, info->max_memkb);
>     ents[2] = "memory/target";
>     ents[3] = GCSPRINTF("%"PRId64, info->target_memkb - info->video_memkb);
> 
>   So target = static-max - (-1):

Aha, well spotted!
   
>       /local/domain/3/memory/static-max = "716800"
>       /local/domain/3/memory/target = "716801"
> 
>   Maybe this is the root cause why we include LIBXL_MAXMEM_CONSTANT.

I don't think so, LIBXL_MAXMEM_CONSTANT is the result of some
not-well-understood folklore which predates libxl entirely.

> 
> Potential solutions:
> 
> 1. Set b_info->video_memkb = 0; for pv guest.

We should do this one, in the libxl_domain_build_info_setdefault
function.

> 2. Set LIBXL_MEMKB_DEFAULT = 0 (instead of -1): this will affect a lot things.

Yeah, we can't do that since it would disallow setting certain kinds of
memory to 0, which can make sense.

> 3. Also add LIBXL_MAXMEM_CONSTANT before doing comparison. (we should avoid 
> this as we want to remove LIBXL_MAXMEM_CONSTANT)

Agreed, lets not to this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel