All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@amd.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: libvir-list@redhat.com, qemu-devel@nongnu.org,
	Bharata B Rao <bharata@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] qemu -numa option and non-contiguous CPU ranges
Date: Thu, 21 Jun 2012 23:39:46 +0200	[thread overview]
Message-ID: <4FE394A2.8070709@amd.com> (raw)
In-Reply-To: <20120621175125.GJ5073@otherpad.lan.raisama.net>

On 06/21/2012 07:51 PM, Eduardo Habkost wrote:
> Hi,
>
> I just noticed libvirt tries to use the -numa option in a way that qemu
> never understood: if a node is configured to have a non-contiguous set
> of CPUs, it tries to generate a command-line option that looks like:
>
> "-numa node,nodeid=...,cpus=0,2,4,mem=..."
>                              ^^^^^
>
> But this format was never supported by qemu. This format is even a bit
> weird, as "," is an option separator, and it is being used as a
> separator _inside_ an option.

Exactly this was the reason back then to not support non-contiguous set 
of CPUs. Inside qemu there is no reason why this shouldn't work, it was 
just hard to write on the command line. So after a short discussion we 
decided to drop this for the time being. If you have a great idea how to 
specify this (I think a comma will not work, because it will be catched 
earlier), I am all ears.

Regards,
Andre.

> My question is: should we support this option format in qemu, or should
> we change libvirt to use another format (that has yet to be implemented,
> because currently there's no way to specify a non-contiguous set of CPUs
> for a NUMA node).
>
> Any suggestions?
>


-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

  reply	other threads:[~2012-06-21 22:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-21 17:51 [Qemu-devel] qemu -numa option and non-contiguous CPU ranges Eduardo Habkost
2012-06-21 21:39 ` Andre Przywara [this message]
2012-06-22 10:00   ` Daniel P. Berrange
2012-06-22 15:18     ` 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=4FE394A2.8070709@amd.com \
    --to=andre.przywara@amd.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=ehabkost@redhat.com \
    --cc=libvir-list@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.