Re: [Xen-devel] [RFC v2][PATCH 1/3] docs: design and intended usage for NUMA-aware ballooning

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On ven, 2013-08-16 at 14:21 +0100, Jan Beulich wrote:
> >>> On 16.08.13 at 12:12, Li Yechen <lccycc123@xxxxxxxxx> wrote:
> > On Fri, Aug 16, 2013 at 5:09 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >> And finally, coming back what Tim had already pointed out - doing
> >> things the way you propose can cause an imbalance in the
> >> ballooned down guest, penalizing it in favor of not penalizing the
> >> intended consumer of the recovered memory. Therefore I wonder
> >> whether, without any new xenstore node, it wouldn't be better to
> >> simply require conforming balloon drivers to balloon out memory
> >> evenly across the domain's virtual nodes.
> > 
> > I should say sorry here, but I'm not quite understand the "whether" part.
> > the "new xenstore node" just store the requirement from user, so that
> > balloon could read it. It's similar to ~/memory/target. This new node
> > could store either p-nodeid, or v-nodeid, according to the interfaces we
> > talked above is placed inside of xen, or inside of guest OS.
> > Do you have a better way to pass this requirement to balloon, instead of
> > create a new xenstore node? I'd be very happy if you have one, since
> > nor do I like the way I have done(create a new node) already!
> 
> As said - I'd want you to evaluate a model without such a new node,
> and with instead the requirement placed on the balloon driver to
> balloon out pages evenly allocated across the guest's virtual nodes.
> 
Why not supporting both modes? I mean, Jan, I totally see what you mean,
and I agree, a very important use case is where the user just says
"balloon down/up", in which case reclaiming/populating evenly is the
most sane thing to do (as also said by David --I think he was him rather
than Tim).

However, what about the use case when the user actually want to make
space on a specific p-node, no matter what it will cost to the existing
guests? I don't have that much "ballooning experience", so I am
genuinely asking here, is that use case completely irrelevant? I
personally thing it would be something nice to have, although, again,
probably not as the default behaviour...

What about something like, the default is the even distribution, but if
the user makes it clear he wants a specific p-node (whatever v-node or
v-nodes that will mean for the guest), we also allow that?

For actually doing it, I'm not sure what the best interface would be...
The new xenstore key did not look perfect, but not that bad even. FWIW,
if we'd stick with it, I agree with you that it should host v-nodes (so
the hypercall doing the translation should happen in the toolstack), and
that it should host a mask.

> > You are exactly right again, this design is only for Linux balloon driver.
> > For Linux, balloon can choose which page to balloon in/out. So we can
> > assocate the pages with v-nodeid.
> > For the other kinds of architechure, please forgive me that I haven't think
> > of that far...
> 
> The abstract model shouldn't take OS implementation details or
> policies into account; the implementation later of course can (and
> frequently will need to).
> 
You are right. Although it is true that this series is specifically for
Linux, Linux specific concepts populates the design document too much,
or at least in the wrong places. :-)

That being said (and perhaps Yechen could make a not about this, so that
if he send another version, he could reorganize this patch/document a
bit, to achieve a better separation between the generic model
description and the implementation details), if you consider all this
the description of the Linux specific implementation, it would be
interesting to know what you think of such specific implementation. :-)

Thanks a lot for taking a look and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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