| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [RFC] Xen NUMA strategy
> >There may be some usage scenarios where having a large SMP guest that
> >spans multiple nodes would be desirable. However, there's a bunch of
> >scalability works that's required in Xen before this will really make
> >sense, and all of this is much higher priority (and more generally
> >useful) than figuring out how to expose NUMA topology to guests. I'd
> >definitely encourage looking at the guest scalability issues first.
>
> What have you said maybe true, many of guests have small numbers
> of vCPUs. In this situation, we need to pin guest to node for good
> performance.
> Pining guest to node may lead to imbalance after some creating and
> destroying guest. We also need to handle imbalance. Better host NUMA
> support is needed.
Localhost relocate is a crude way of doing this rebalancing today. Sure,
we can do better, but it's a solution.
> Even we don't have big guest, we may also need to let guest span
> NUMA node. For example, when we create a guest which has big memory,
> none of the NUMA node can satisfy the memory request, so this guest
has
> to span NUMA node. We need to provide guest the NUMA information.
In that far from optimal situation you'll likely to want to try and
rebalance things at some point later. Since no guest OS I'm aware of
understands dynamic NUMA information I seriously doubt there's any good
can come from telling it about the temporary situation.
> There is still very small NUMA node. May be one CPU per node, if
> guest has two vCPUs, we need provide guest NUMA information, and
> otherwise it will impact performance badly.
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home