[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1 of 3 v5/leftover] libxl: enable automatic placement of guests on NUMA nodes [and 1 more messages]
On Wed, 2012-07-18 at 10:13 +0100, Ian Campbell wrote: > On Wed, 2012-07-18 at 01:22 +0100, Dario Faggioli wrote: > > > So, to summarize, I can't be farther than saying the current algorithm > > is perfect or fast. Rather, I'm definitely saying it has the advantage > > of not branching out the problem space too much aggressively at this > > early stage, and it is flexible enough for avoiding getting unreasonable > > performances, or at least, it looks like that to me, I guess. :-) > > I'm not quite following what you are trying to say with all this. > Oh, I see, sorry. :-( > Are you saying that the code as most recently submitted does not have > the O( C(nr_nodes,min_nodes) ) property which Ian J suggests, which > leads to needing to process hundreds of millions of combinations for a > 16 / 32 node guest? > No, I'm not. If you want to place a 16 (32) nodes guest on a 32 (64) nodes host, it is as bad as he says. However, I'm also saying that on <=16 nodes host it is able o provide very good placement at a reasonable cost and that, if we limit the number of guest nodes (e.g., up to 4) it is able to do the same even on 32 or 64 nodes hosts. > Or are you saying that it does have this property > but it doesn't matter? > A lot of people is thinking that trying to address the problem of placing guests that are bigger (or anyway, guests that does not fit) in just 1 node should not be even considered. I'm saying that it should and am also proposing an algorithm that is able to provide good placement performances for guests that spans up to 4 nodes even on future 32 or 64 nodes systems. So basically I'm saying that it does have that property but that is bringing benefits right now, and we have all the knobs to limit its potential nasty effects for future (bigger) system at any time. > Or are you saying it does have this property but > you intend to ameliorate it somehow? If the latter then how and for > which release(s) (4.2, 4.3 or 4.2.1)? > Yes, I guess I'm sort of saying something like that. What could be done is restricting automatic placement to guests that fits on 4 or 8 nodes for 4.2. Then, for 4.3 (and with a very small backport effort to 4.2.1), implement a lighter solution for dealing with the ones that does not. Hope I clarified at least a bit. :-) Thanks and Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |