All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hu Tao <hutao@cn.fujitsu.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	Nishanth Aravamudan <nacc@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, Anton Blanchard <anton@samba.org>,
	David Rientjes <rientjes@google.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH v3] numa: enable sparse node numbering
Date: Thu, 26 Jun 2014 17:09:25 +0800	[thread overview]
Message-ID: <20140626090924.GA12168@G08FNSTD100614.fnst.cn.fujitsu.com> (raw)
In-Reply-To: <20140625182317.GG16636@redhat.com>

On Wed, Jun 25, 2014 at 09:23:17PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 01:52:56PM -0300, Eduardo Habkost wrote:
> > On Wed, Jun 25, 2014 at 09:13:59AM -0700, Nishanth Aravamudan wrote:
> > > On 25.06.2014 [13:21:34 +0200], Igor Mammedov wrote:
> > > > On Tue, 24 Jun 2014 10:40:38 -0700
> > > > Nishanth Aravamudan <nacc@linux.vnet.ibm.com> wrote:
> > > <snip>
> > > > > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > > > > index 277230d..b90bf66 100644
> > > > > --- a/include/sysemu/sysemu.h
> > > > > +++ b/include/sysemu/sysemu.h
> > > > > @@ -145,11 +145,13 @@ extern int mem_prealloc;
> > > > >   */
> > > > >  #define MAX_CPUMASK_BITS 255
> > > > >  
> > > > > -extern int nb_numa_nodes;
> > > > > +extern int nb_numa_nodes; /* Number of NUMA nodes */
> > > > > +extern int max_numa_node; /* Highest specified NUMA node ID */
> > > > >  typedef struct node_info {
> > > > >      uint64_t node_mem;
> > > > >      DECLARE_BITMAP(node_cpu, MAX_CPUMASK_BITS);
> > > > >      struct HostMemoryBackend *node_memdev;
> > > > > +    bool present;
> > > > How about dropping 'present' and replacing array with a list
> > > > of only present nodes?
> > > 
> > > If that would be preferred, I can move to that. I assume a simple
> > > linked-list is fine. Does qemu provide any infrastructure for defining
> > > lists? I'll look through the source but any pointers would be helpful.
> > > 
> > > Generally speaking, sparse NUMA nodes aren't that common and when they
> > > exist, the gaps aren't large. But it does seem to make sense if we have
> > > sparse IDs at all, we might as well move to a list.
> > > 
> > > In any case, moving to the list means we'd have a nodeid as part of the
> > > structure instead.
> > > 
> > > > That way it will be one more step closer to converting numa
> > > > infrastructure to a set of QOM objects.
> > > 
> > > Sounds like a good idea to me. I'll respin the patch soon.
> > 
> > Having a list makes sense, the only difference is that keeping a sparse
> > array sorted is much easier than making a sorted list (because the ACPI
> > tables are nodeid-ordered). That's why I suggested keeping the array
> > initially.
> > 
> > Adding a "present" field to the array is a trivial and easy-to-review
> > change. Changing NodeInfo to use linked lists is a more complex change
> > that I wouldn't want to include after soft freeze.
> > 
> > In other words:
> >  * Having a list is better than a sparse array; but:
> >  * Having a small sparse array with the "present" field is better
> >    than broken sparse nodeid support (IMO).
> 
> I agree here. This patchset is still RFC but if that's
> the only issue I might apply it.

I don't think it is ready for 2.1 since it lacks arch-specific changes.
The patch itself only makes qemu be able to bring up guest with sparse
numa nodes, without arch-specific changes, guest sees only one node(at
least on x86).

Hu

  reply	other threads:[~2014-06-26  9:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 19:33 [Qemu-devel] [RFC PATCH] numa: enable sparse node numbering Nishanth Aravamudan
2014-06-24  0:48 ` [Qemu-devel] [RFC PATCH v2] " Nishanth Aravamudan
2014-06-24  1:08   ` [Qemu-devel] [RFC PATCH] ppc/spapr: support sparse NUMA " Nishanth Aravamudan
2014-06-24  3:34     ` Nishanth Aravamudan
2014-06-24  7:43   ` [Qemu-devel] [RFC PATCH v2] numa: enable sparse " Hu Tao
2014-06-24 17:40   ` [Qemu-devel] [RFC PATCH v3] " Nishanth Aravamudan
2014-06-25 11:21     ` Igor Mammedov
2014-06-25 16:13       ` Nishanth Aravamudan
2014-06-25 16:52         ` Eduardo Habkost
2014-06-25 17:04           ` Nishanth Aravamudan
2014-06-25 18:24             ` Michael S. Tsirkin
2014-06-26  6:29             ` Igor Mammedov
2014-06-25 18:23           ` Michael S. Tsirkin
2014-06-26  9:09             ` Hu Tao [this message]
2014-06-26 17:58               ` Nishanth Aravamudan
2014-06-26 18:39                 ` Eduardo Habkost
2014-06-26 19:37     ` Eduardo Habkost
2014-06-30 18:26       ` Nishanth Aravamudan
2014-06-30 21:48         ` Eduardo Habkost
2014-06-24  7:33 ` [Qemu-devel] [RFC PATCH] " Igor Mammedov
2014-06-24  8:58   ` Alexey Kardashevskiy
2014-06-24 16:39   ` Nishanth Aravamudan

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=20140626090924.GA12168@G08FNSTD100614.fnst.cn.fujitsu.com \
    --to=hutao@cn.fujitsu.com \
    --cc=aik@ozlabs.ru \
    --cc=anton@samba.org \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=nacc@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rientjes@google.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.