From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org, Hu Tao <hutao@cn.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH v4 1/1] numa: Print warning if no node is assigned to a CPU
Date: Wed, 4 Mar 2015 14:50:59 +0100 [thread overview]
Message-ID: <20150304135059.GB29478@redhat.com> (raw)
In-Reply-To: <20150304133551.GO3513@thinpad.lan.raisama.net>
On Wed, Mar 04, 2015 at 10:35:51AM -0300, Eduardo Habkost wrote:
> On Wed, Mar 04, 2015 at 01:30:35PM +0100, Michael S. Tsirkin wrote:
> > On Tue, Feb 24, 2015 at 03:57:23PM -0300, Eduardo Habkost wrote:
> > > Instead of silently assigning CPU to node 0 when it is omitted from the
> > > command-line, check if all CPUs up to max_cpus are present in the NUMA
> > > configuration.
> >
> > Could you please describe the problematic configuration
> > in more detail in commit log?
> > Also, how does this interact with cpu hotplug?
>
> I will try to reword the message to make it clearer. Suggestions are
> welcome.
Just include the command line that reproduces the problem,
and describe the guest behaviour that results.
> Basically, the problem is:
>
> * Currently all possible CPUs (including hotplug ones) need to be
> present in the SRAT when QEMU is started[1]. QEMU already does that.
> * When a CPU is ommitted from the command-line, QEMU is silently
> assigning it to node 0. This is not a very useful default and
> just confuse users.
It's reasonable if user doesn't want to play with numa, isn't it?
>
> > >
> > > I am making this a warning and not a fatal error, to allow management
> > > software to be updated if necessary.
> > >
> > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > ---
> > > v1 -> v2: (no changes)
> > >
> > > v2 -> v3:
> > > * Use enumerate_cpus() and error_report() for error message
> > > * Simplify logic using bitmap_full()
> > >
> > > v3 -> v4:
> > > * Clarify error message, mention that all CPUs up to
> > > maxcpus need to be described in NUMA config
> > > ---
> > > numa.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/numa.c b/numa.c
> > > index 9a3fc15..d8021b9 100644
> > > --- a/numa.c
> > > +++ b/numa.c
> > > @@ -201,6 +201,16 @@ static void validate_numa_cpus(void)
> > > bitmap_or(seen_cpus, seen_cpus,
> > > numa_info[i].node_cpu, MAX_CPUMASK_BITS);
> > > }
> > > +
> > > + if (!bitmap_full(seen_cpus, max_cpus)) {
> > > + char *msg;
> > > + bitmap_complement(seen_cpus, seen_cpus, max_cpus);
> > > + msg = enumerate_cpus(seen_cpus, max_cpus);
> > > + error_report("warning: CPU(s) not present in any NUMA nodes: %s", msg);
> > > + error_report("warning: All CPU(s) up to maxcpus should be described "
> > > + "in NUMA config");
> >
> > What happens with e.g. windows guests when this warning is emitted?
> > do they blue-screen?
>
> As described on the commit log above, the CPU is silently assigned to
> node 0 when it is omitted from the command-line. In other words, this
> won't make guests confused, but can make users confused.
>
> All possible VCPUs (including the hotplug ones, i.e. up to max_cpus) are
> expected to be present in the SRAT, and they are already present. The
> only problem is that instead of complaining about missing CPUs, QEMU is
> assigning node 0 to them.
>
> --
> Eduardo
next prev parent reply other threads:[~2015-03-04 13:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 18:57 [Qemu-devel] [PATCH v4 0/1] NUMA: Validate CPU configuration Eduardo Habkost
2015-02-24 18:57 ` [Qemu-devel] [PATCH v4 1/1] numa: Print warning if no node is assigned to a CPU Eduardo Habkost
2015-03-04 12:25 ` Eduardo Habkost
2015-03-04 12:30 ` Michael S. Tsirkin
2015-03-04 13:35 ` Eduardo Habkost
2015-03-04 13:50 ` Michael S. Tsirkin [this message]
2015-03-04 14:08 ` Eduardo Habkost
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=20150304135059.GB29478@redhat.com \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=hutao@cn.fujitsu.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.