From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47036)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ehabkost@redhat.com>) id 1WzqRf-0005PI-H2
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 12:53:22 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ehabkost@redhat.com>) id 1WzqRW-0008Gu-J7
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 12:53:15 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51044)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ehabkost@redhat.com>) id 1WzqRW-0008GA-An
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 12:53:06 -0400
Date: Wed, 25 Jun 2014 13:52:56 -0300
From: Eduardo Habkost <ehabkost@redhat.com>
Message-ID: <20140625165256.GD3222@otherpad.lan.raisama.net>
References: <20140623193310.GD4323@linux.vnet.ibm.com>
	<20140624004825.GE4323@linux.vnet.ibm.com>
	<20140624174038.GK4323@linux.vnet.ibm.com>
	<20140625132134.24b70a65@nial.usersys.redhat.com>
	<20140625161359.GA8698@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140625161359.GA8698@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC PATCH v3] numa: enable sparse node numbering
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, Alexey Kardashevskiy <aik@ozlabs.ru>, Hu Tao <hutao@cn.fujitsu.com>, qemu-devel@nongnu.org, Anton Blanchard <anton@samba.org>, David Rientjes <rientjes@google.com>, Igor Mammedov <imammedo@redhat.com>

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).

<rant>
Improving the code is always welcome (and adding a list would be an
improvement), but we don't need to implement all refactoring changes we
can dream of, before including a new feature. I like to evaluate how the
code looks like compared to what we have today, not with what we want it
to look like in one year.

Could we (the QEMU community) please learn to sometimes accept simple
features or fixes (which don't make the code worse) without requiring
the whole code to be rewritten first?
</rant>

-- 
Eduardo