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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

[For this message and for all the othr I'm sending today, sorry for the webmail 
:-P]

From: Jan Beulich [jbeulich@xxxxxxxx]
>>>> Dario Faggioli <dario.faggioli@xxxxxxxxxx> 08/17/13 1:31 AM >>>
>>Suppose we have guest G with 2 v-nodes and with pages in v-node 0 (say,
>>page 0,1,2..N-1) are backed by frames on p-node 2, while pages in v-node
>>1 (say, N,N+1,N+2..2N-1) are backed by frames on p-node 4, and that is
>>because, at creation time, either the user or the toolstack decided this
>>was the way to go.
>>So, if page 2 was ballooned down, when ballooning it up, we would like
>>to retain the fact that it is backed by a frame in p-node 2, and we
>>could ask Xen to try make that happen. On failure (e.g., no free frames
>>on p-node 2), we could either fail or have Xen allocate the memory
>>somewhere else, i.e., not on p-node 2 or p-node 4, and live with it
>>(i.e., map G's page 2 there), which I think is what you mean with <<node
>>the domain so far was "knowing" of>>, isn't it?
>
>Right. Or the guest could choose to create a new node on the fly.
>
>Jan
>
Are you talking of a guest creating a new virtual node, i.e., changing it's
own (virtual) NUMA topology on the fly? If yes, that could be an option
too, I guess.

It is not something we plan to support in the first implementation of
virtual NUMA for Linux, but since we are talking about making this
spec document more general, yes I think we should not rule-out
such a possibility.

Thanks 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)

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