|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: NUMA and SMP
* Daniel Stodden <stodden@xxxxxxxxxx> [2007-03-22 10:41]:
> On Thu, 2007-03-22 at 10:12 -0500, Ryan Harper wrote:
> > * Daniel Stodden <stodden@xxxxxxxxxx> [2007-03-22 10:03]:
> > > On Thu, 2007-03-22 at 08:02 -0500, Ryan Harper wrote:
> > >
> > > > > > and for the paravirt xen-guest-linux do not support numa-aware
> > > > > > now ,or
> > > > > > does it support numa-aware if CONFIG_NUMA choiced?
> > > > >
> > > > > no. there is num-support in xen, as far as inspection of the memory
> > > > > topology and inclusion in the memory management is concerned. so
> > > > > basically, you can add the desired node number to get_free_pages().
> > > >
> > > > There is NUMA support in Xen since 3.0.4 in the hypervisor, and we have
> > > > the capability to ensure a guest memory is local to the processors being
> > > > used. The topology of the system is not exported to the guest so
> > > > CONFIG_NUMA in the guest kernel config will be of no value.
> > >
> > > oops, that's more than i've noticed. thanks for the correction. so now
> > > it seems up to me to ask questions. :} i don't see that path taken along
> > > vcpu_migrate. where is it happening?
> >
> > The credit scheduler is not NUMA aware. So to ensure that the initial
> > allocation for the guest remains local, the domain uses a cpumask
> > (generated from cpus="" config file option) to keep the scheduler from
> > migrating vcpus to off-node cpus.
>
> i see. not like i'm too deep in the srat, but methinks there may be sane
> default values to be generated from the srat. any work happening or
> having happened on that front?
Xen understands the topology but does not make any direct use of the
information in either the initial placement of VCPUs for the guest, nor
in the scheduler when making migration decisions. I'm not aware of any
work to address that at the moment.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@xxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] Re: NUMA and SMP, (continued)
- Re: [Xen-devel] Re: NUMA and SMP, tgh
- Re: [Xen-devel] Re: NUMA and SMP, Daniel Stodden
- Re: [Xen-devel] Re: NUMA and SMP, tgh
- Re: [Xen-devel] Re: NUMA and SMP, Daniel Stodden
- Re: [Xen-devel] Re: NUMA and SMP, tgh
- Re: [Xen-devel] Re: NUMA and SMP, Daniel Stodden
- Re: [Xen-devel] Re: NUMA and SMP, Ryan Harper
- Re: [Xen-devel] Re: NUMA and SMP, Daniel Stodden
- Re: [Xen-devel] Re: NUMA and SMP, Ryan Harper
- Re: [Xen-devel] Re: NUMA and SMP, Daniel Stodden
- Re: [Xen-devel] Re: NUMA and SMP,
Ryan Harper <=
- Re: [Xen-devel] Re: NUMA and SMP, Daniel Stodden
- Re: [Xen-devel] Re: NUMA and SMP, Ryan Harper
- Re: [Xen-devel] Re: NUMA and SMP, tgh
- Re: [Xen-devel] Re: NUMA and SMP, Ryan Harper
- RE: [Xen-devel] Re: NUMA and SMP, Petersson, Mats
- Re: [Xen-devel] Re: NUMA and SMP, tgh
- Re: [Xen-devel] Re: NUMA and SMP, Ryan Harper
- [Xen-devel] The context switch overhead comparison between vmexit/vmentry and hypercall., Liang Yang
|
|
|
|
|