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

[Li Yechen <lccycc123@xxxxxxxxx>]

Hi all,

Sorry for my being absent for a month.... And congratulate to Elena for your patches!  I'll read them if I'm free~~

In conclusion, there are two things for the NUMA support bubble:

First,
>If we decide we do need such control, I think the xenstore interface
>should look more like:
>
>memory/target
>
>  as before
>
>memory/target-by-nid/0
>
>  target for virtual node 0
>
>...
>
>memory/target-by-nid/N
>
>  target for virtual node N
>
>I think this better reflects the goal which is an adjusted NUMA layout
>for the guest rather than the steps required to reach it (release P
>pages from node N).

Yes I think this is a very good idea. However, if target is conflict with the sum of target-by-nid/xxx, bubble may be confused..

My idea is something as:

1 User can know the target tree, for example:

memory/target
memory/target-by-nid/0
memory/target-by-nid/1
memory/target-by-nid/2

2 User can use xl tool to set one of them to an specified value.

   For example: user set memory/target-by-nid/0 from 100M to 200M

   then that means: increase both memory/target and memory/target-by-nid/0 by 100M

   Another example: user set memory/target from 800M to 900M

   then that means: increase memory/target by 100M, but balloon could make decision by its own.

  Does that make sencse?

3 In domU, balloon receive that which directory is changed. then it balloon in/out pages from the node(s).

Second:
>I think exposing any NUMA topology to guest - irregardless whether it is based
> on real NUMA or not, is OK - and actually a pretty neat thing.
>
>Meaning you could tell a PV guest that it is running on a 16 socket NUMA
>box while in reality it is running on a single socket box. Or vice-versa.
>It can serve as a way to increase performance (or decrease) - and also
>do resource capping (This PV guest will only get 1G of real fast
>memory and then 7GB of slow memory) and let the OS handle the details
> of it (which it does nowadays).
>
> The mapping thought - of which PV pages should belong to which fake
> PV NUMA node - and how they bind to the real NUMA topology - that part
> I am not sure how to solve. More on this later.

   Here is the question: should the interface: machine_node_id_to_virtual_node_id   (and also the reverse)  be inplememted inside kernel, or in Xen as a hypercall?

   Elena, I haven't have time to look at your great patches so that I have no idea whether you had implememted it or no....

   If you had, I'd say sorry that we still need to talk about it : - )

   I think to implement them as a hypercall in xen is very nice, since domU shouldn't know hypervisior's NUMA architecture....

             But that also means: I have to change three hypercalls about memory operation.....
            

  On the other hand, implement them in Kernel is pretty neat, but it goes against the rule of isolation....

  Anyway I prefer the previous one. Could you guys give me some ideas?

Thank you again for your suggestions on this topic : )

--

Yechen Li

Team of System Virtualization and Cloud Computing 
School of Electronic Engineering  and Computer Science, 
Peking University, China

Nothing is impossible because impossible itself  says: " I'm possible "

lccycc From PKU

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