All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Andre Przywara <andre.przywara@amd.com>
Cc: Christoph Egger <christoph.egger@amd.com>,
	Ryan Harper <ryanh@us.ibm.com>, Keir Fraser <keir@xensource.com>,
	xen-devel@lists.xensource.com
Subject: Re: [PATCH 2/4] [HVM] introduce CPU affinity for allocate_physmap call
Date: 15 Aug 2007 13:18:10 +0200	[thread overview]
Message-ID: <p73643h2gi5.fsf@bingen.suse.de> (raw)
In-Reply-To: <46C2D1A8.1030001@amd.com>

"Andre Przywara" <andre.przywara@amd.com> writes:

> Ryan Harper wrote:
> > One concern has been the static nature of the ACPI SRAT data versus the
> > dynamic ability of the vcpu to cpu mapping.  If the scheduler is
> > migrating the guest vcpu to various cpus, then the SRAT information is
> > likely to be incorrect.
> I think this is a problem even for the native OSes when you think of
> CPU- and/or memory-hotplugging. Although Linux can do CPU hotplugging,
> AFAIK NUMA isn't currently considered in this process. 

IA64 (and I think PPC) Linux support node hotplug. Node hot unplug
is currently missing because the memory hotunplug support is not finished
yet. There is no interface to notify NUMA aware user space of topology
changes though.

x86 Linux currently doesn't but will assign new CPUs to existing
nodes as reported in SRAT.

> I think the
> most feasible approach would be to rebuild all affected structures
> when the hotplug event occurs. This will probably considered quite
> rare and thus could be potentially more costly, so I this is not
> something you want to do every time Xen decides to reschedule a
> VCPU. 

In the current Linux implementation just report all nodes at boot up
(even if they have little or no memory) and then you can add/remove CPUs to 
them as needed. 

When you migrate to another box with more nodes that likely won't work,
but that could be probably made configurable.

-Andi

  reply	other threads:[~2007-08-15 11:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-13 10:02 [PATCH 2/4] [HVM] introduce CPU affinity for allocate_physmap call Andre Przywara
2007-08-13 10:30 ` Keir Fraser
2007-08-13 12:59   ` Christoph Egger
2007-08-13 14:00     ` Isaku Yamahata
2007-08-13 14:06     ` Keir Fraser
2007-08-13 20:49       ` Ryan Harper
2007-08-15 10:12         ` Andre Przywara
2007-08-15 11:18           ` Andi Kleen [this message]
2007-08-15 10:13       ` Andre Przywara
2007-08-15 10:43         ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=p73643h2gi5.fsf@bingen.suse.de \
    --to=andi@firstfloor.org \
    --cc=andre.przywara@amd.com \
    --cc=christoph.egger@amd.com \
    --cc=keir@xensource.com \
    --cc=ryanh@us.ibm.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.