qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 0/7] spapr: rework memory nodes
Date: Mon, 16 Jun 2014 22:41:08 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

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.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]