[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging



On Tue, 2012-02-21 at 12:20 +0000, George Dunlap wrote:
> On Tue, 2012-02-21 at 09:59 +0000, Ian Campbell wrote:

> > So why not make the "on" case the same as your "delay" case and do away
> > with the distinction? If advanced users really want what you describe as
> > "on" then they can set the delay to 0.
> 
> The only thing with this is that then the command will by default pause
> until we reach the target, which may be several seconds.  We should make
> sure to print a message saying that's what we're doing, so users don't
> get confused.

I'm not sure this isn't actually a feature...

$ xl mem-set dom 128
xl: setting domain `dom' memory target to 128M
xl: waiting for domain to reach target: 60... 55... 50... (etc) 5... timeout!
xl: domain `dom' did not reach target (reached 156M)
xl: enabling paging, setting domain footprint to 128M.

> > > xl mem-balloon-set domain M
> > >  Set balloon target to M
> > > xl mem-paging-set domain M
> > >  Set paging target to M
> > 
> > How do these interact with mem-set. Especially in the delay case?
> 
> My idea was that "xl mem-paging-set domain M" would basically be
> equivalent to xenstore-write /local/[whatever]/[whatever]: that is, no
> attempt at synchronization.  If I do "xl mem-set" with a delay in one
> window, then do "xl mem-paging-set" in another window, the first one
> will take effect immediately, then the other one will take effect after
> the delay.  If that's not what you want, either Ctrl-C the first one or
> wait for it to finish. :-)
> 
> > e.g. would mem-paging-set disable the after delay behaviour of mem-set?
> > Should we have "mem-paging-set domain auto" to turn that back on?
> 
> That's one of the reasons I conceived having mem-balloon-set: if you
> want to switch to full-manual, you just switch to using full-manual
> commands.  If/when you have stuff in a state that the simpler command
> will work again, you can switch back.

What if you switch back without making sure you are in such a state? I
think switching between the two is where the potential for unexpected
behaviour is most likely.

> 
> > How about the following? I've tried to include the "user facing"
> > description as well as the actual implementation. I think the "user
> > facing" portion is actually where we disagree but I also suspect that we
> > may not actually disagree -- it's just that we are talking in terms of
> > implementation so we don't see that the user facing interface is the
> > same in what we are each thinking of ;-)
> > 
> > maxmem=X                    # maximum RAM the domain can ever see
> > memory=M                    # current amount of RAM seen by the domain
> > paging=[off|on]                     # allow the amount of memory a guest 
> >                             # thinks it has to differ from the
> >                             # amount actually available to it (its
> >                             # "footprint")
> > pagingauto=[off|on] (dflt=on)   # enable automatic enforcement of 
> >                             # "footprint" for guests which do not
> >                             # voluntarily obey changes to memory=M 
> > pagingdelay=60                      # amount of time to give a guest to 
> >                             # voluntarily comply before enforcing a 
> >                             # footprint
> > 
> > xl mem-set domain M
> >         Sets the amount of RAM which the guest believes it has available
> >         to M. The guest should arrange to use only that much RAM and
> >         return the rest to the hypervisor (e.g. by using a balloon
> >         driver). If the guest does not do so then the host may use
> >         technical means to enforce the guest's footprint of M. The guest
> >         may suffer a performance penalty for this enforcement.
> > 
> >     paging off:     set balloon target to M.
> >     paging on:      set balloon target to M.
> >                     if pagingauto:
> >                             wait delay IFF new target < old
> >                             set paging target to M
> >                             support -t <delay> to override default?
> > 
> > xl mem-paging-set domain N
> >         Overrides the amount of RAM which the guest actually has
> >         available (its "footprint") to N. The host will use technical
> >         means to continue to provide the illusion to the guest that it
> >         has memory=M (as adjusted by mem-set). There may be a
> >         performance penalty for this.
> >         
> >     paging off:     error
> >     paging on:      set paging target
> >                     set pagingauto=off
> > 
> > xl mem-paging-set domain auto
> >         Automatically manage paging. Request that the guest uses
> >         memory=M (current value of memory, as adjusted by mem-set)
> >         enforced when the guest is uncooperative (as described in
> >         "mem-set")
> >         
> >     paging off:     error
> >     paging on:      set paging target to M
> >                     set pagingauto=on
> > 
> > No need for a separate balloon-set since that == mem-set with
> > pagingauto=off.
> > 
> > Perhaps a separate "mem-paging-set domain manual" would be handy to
> > enable that mode without having to remember M so you can use it as N 
> 
> I'd be OK with this.

Great.

I like that you have to explicitly ask for the safety wheels to come off
and explicitly put them back on again. It avoids the corner cases I
alluded to above (at least I hope so).

> 
> > We could consider making "mem-paging-set domain N" fail with an error
> > unless you previously set manual, to prevent users accidentally
> > disabling the recommended automatic behaviour e.g. by typing
> > mem-paging-set when they mean mem-set.
> > 
> > I liked Andres' suggestions of footprint as a term here BTW so I would
> > prefer "mem-footprint-set" to "mem-paging-set" (at least I think so, I'm
> > not 100% on that). If we don't have balloon-set then avoiding the name
> > paging seems like a good idea too. Other possible names might be
> > "mem-override-set" or something.
> 
> Well for one, "footprint" to me would imply "I don't care how you got
> there, just make it take this much memory".  So saying in the docs that
> "xl mem-set" would attempt to set the memory footprint would be OK.  But
> I definitely don't think we should use "footprint" to mean "paging
> target".  Even apart from the fact that the name to me means something
> else, the config options are called "paging".  In any case, if it's
> supposed to be an "advanced feature", it should be OK to expect the user
> to know (or find out) what paging means.

I see what you mean, yes.

Without wishing to put words in Andres' mouth I expect that he intended
"footprint" to cover other technical means than paging too --
specifically I expect he was thinking of page sharing. (I suppose it
also covers PoD to some extent too, although that is something of a
special case)

While I don't expect there will be a knob to control number of shared
pages (either you can share some pages or not, the settings would be
more about how aggressively you search for sharable pages) it might be
useful to consider the interaction between paging and sharing, I expect
that most sharing configurations would want to have paging on at the
same time (for safety). It seems valid to me to want to say "make the
guest use this amount of actual RAM" and to achieve that by sharing what
you can and then paging the rest.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.