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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Dario Faggioli <dario.faggioli@xxxxxxxxxx> 08/17/13 12:53 AM >>>
>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?

Yes, supporting both modes is certainly desirable; I merely tried to
point out that the description went too far in the direction of advocating
only the enforce-a-node model (almost like this was the only sensible
one from the NUMA perspective). Penalizing another guest should
clearly not be a default action, but it may validly be a choice by the
administrator.

Jan

Jan


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