Re: [Qemu-devel] [PATCH 0/7] spapr: rework memory nodes

[Nishanth Aravamudan <nacc@linux.vnet.ibm.com>]

On 16.06.2014 [22:41:08 -0300], Eduardo Habkost wrote:
> On Mon, Jun 16, 2014 at 05:25:00PM -0700, Nishanth Aravamudan wrote:
> [...]
> > > But you seem to claim you need 3 nodes with non-contiguous IDs. In that
> > > case, which exactly is the guest-visible difference you expect to get
> > > between:
> > >   -numa node,nodeid=0,cpus=0-7,memory=0 \
> > >   -numa node,nodeid=1 \
> > >   -numa node,nodeid=2,cpus=0-3,mem=1040 \
> > >   -numa node,nodeid=3 \
> > >   -numa node,nodeid=4,cpus=4-7,mem=1040
> > 
> > I guess here you'd see 5 NUMA nodes in Linux, with 0, 1 and 3 having no
> > memory.
> > 
> > > and
> > >   -numa node,nodeid=0,cpus=0-7,memory=0 \
> > >   -numa node,nodeid=2,cpus=0-3,mem=1040 \
> > >   -numa node,nodeid=4,cpus=4-7,mem=1040
> > > ?
> > 
> > And here you'd see 3 NUMA nodes in Linux, with 0 having no memory. I
> > would think the principle of least surprise means qemu doesn't change
> > the topology from the user-requested one without any indicate that's
> > happening?
> 
> OK, so we are on the same page. The problem is: with your patch, both
> cases above are exactly the same. That's what confused me: I thought you
> wanted to implement the former, but you want the latter.
> 
> When changing the code to allow non-contiguous node IDs, I believe we
> need to differentiate those cases and implement both correctly.
> Otherwise we will be forced to break compatibility in the future.

Yep, I think we need at least one follow-on (or additional) patch in
Alexey's series.

-Nish