[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2][PATCH 1/3] docs: design and intended usage for NUMA-aware ballooning
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~~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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |