qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] qemu -numa option and non-contiguous CPU ranges
@ 2012-06-21 17:51 Eduardo Habkost
  2012-06-21 21:39 ` Andre Przywara
  0 siblings, 1 reply; 4+ messages in thread
From: Eduardo Habkost @ 2012-06-21 17:51 UTC (permalink / raw)
  To: qemu-devel, libvir-list; +Cc: Andre Przywara, Bharata B Rao

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.

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?

-- 
Eduardo

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] qemu -numa option and non-contiguous CPU ranges
  2012-06-21 17:51 [Qemu-devel] qemu -numa option and non-contiguous CPU ranges Eduardo Habkost
@ 2012-06-21 21:39 ` Andre Przywara
  2012-06-22 10:00   ` Daniel P. Berrange
  0 siblings, 1 reply; 4+ messages in thread
From: Andre Przywara @ 2012-06-21 21:39 UTC (permalink / raw)
  To: Eduardo Habkost; +Cc: libvir-list, qemu-devel, Bharata B Rao

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] qemu -numa option and non-contiguous CPU ranges
  2012-06-21 21:39 ` Andre Przywara
@ 2012-06-22 10:00   ` Daniel P. Berrange
  2012-06-22 15:18     ` Eduardo Habkost
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel P. Berrange @ 2012-06-22 10:00 UTC (permalink / raw)
  To: Andre Przywara; +Cc: libvir-list, Bharata B Rao, Eduardo Habkost, qemu-devel

On Thu, Jun 21, 2012 at 11:39:46PM +0200, Andre Przywara wrote:
> 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.

Lets just use a ';' or ':' as the seperator instead ?

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] qemu -numa option and non-contiguous CPU ranges
  2012-06-22 10:00   ` Daniel P. Berrange
@ 2012-06-22 15:18     ` Eduardo Habkost
  0 siblings, 0 replies; 4+ messages in thread
From: Eduardo Habkost @ 2012-06-22 15:18 UTC (permalink / raw)
  To: Daniel P. Berrange; +Cc: libvir-list, Andre Przywara, qemu-devel, Bharata B Rao

On Fri, Jun 22, 2012 at 11:00:57AM +0100, Daniel P. Berrange wrote:
> On Thu, Jun 21, 2012 at 11:39:46PM +0200, Andre Przywara wrote:
> > 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.
> 
> Lets just use a ';' or ':' as the seperator instead ?

Sounds like a better option, instead of making the -numa option parsing
be different from all other options. I was just wondering if it was
worth making some effort to make qemu compatible with the current
libvirt code. (I am inclined to say it is not worth it, as it never
worked before)

-- 
Eduardo

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-06-22 15:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-21 17:51 [Qemu-devel] qemu -numa option and non-contiguous CPU ranges Eduardo Habkost
2012-06-21 21:39 ` Andre Przywara
2012-06-22 10:00   ` Daniel P. Berrange
2012-06-22 15:18     ` Eduardo Habkost

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).