Re: [libvirt] [Qemu-devel] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option

* Igor Mammedov (imammedo(a)redhat.com) wrote: > On Fri, 1 Mar 2019 15:49:47 +0000 > Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > > > On Fri, Mar 01, 2019 at 04:42:15PM +0100, Igor Mammedov wrote: > > > The parameter allows to configure fake NUMA topology where guest > > > VM simulates NUMA topology but not actually getting a performance > > > benefits from it. The same or better results could be achieved > > > using 'memdev' parameter. In light of that any VM that uses NUMA > > > to get its benefits should use 'memdev' and to allow transition > > > initial RAM to device based model, deprecate 'mem' parameter as > > > its ad-hoc partitioning of initial RAM MemoryRegion can't be > > > translated to memdev based backend transparently to users and in > > > compatible manner (migration wise). > > > > > > That will also allow to clean up a bit our numa code, leaving only > > > 'memdev' impl. in place and several boards that use node_mem > > > to generate FDT/ACPI description from it. > > > > Can you confirm that the 'mem' and 'memdev' parameters to -numa > > are 100% live migration compatible in both directions ? Libvirt > > would need this to be the case in order to use the 'memdev' syntax > > instead. > Unfortunately they are not migration compatible in any direction, > if it where possible to translate them to each other I'd alias 'mem' > to 'memdev' without deprecation. The former sends over only one > MemoryRegion to target, while the later sends over several (one per > memdev). > > Mixed memory issue[1] first came from libvirt side RHBZ1624223, > back then it was resolved on libvirt side in favor of migration > compatibility vs correctness (i.e. bind policy doesn't work as expected). > What worse that it was made default and affects all new machines, > as I understood it. > > In case of -mem-path + -mem-prealloc (with 1 numa node or numa less) > it's possible on QEMU side to make conversion to memdev in migration > compatible way (that's what stopped Michal from memdev approach). > But it's hard to do so in multi-nodes case as amount of MemoryRegions > is different. > > Point is to consider 'mem' as mis-configuration error, as the user > in the first place using broken numa configuration > (i.e. fake numa configuration doesn't actually improve performance). > > CCed David, maybe he could offer a way to do 1:n migration and other > way around. I can't see a trivial way. About the easiest I can think of is if you had a way to create a memdev that was an alias to pc.ram (of a particular size and offset).

Dave > > > > Signed-off-by: Igor Mammedov <imammedo(a)redhat.com&gt; > > > --- > > > numa.c | 2 ++ > > > qemu-deprecated.texi | 14 ++++++++++++++ > > > 2 files changed, 16 insertions(+) > > > > > > diff --git a/numa.c b/numa.c > > > index 3875e1e..2205773 100644 > > > --- a/numa.c > > > +++ b/numa.c > > > @@ -121,6 +121,8 @@ static void parse_numa_node(MachineState *ms, NumaNodeOptions *node, > > > > > > if (node->has_mem) { > > > numa_info[nodenr].node_mem = node->mem; > > > + warn_report("Parameter -numa node,mem is deprecated," > > > + " use -numa node,memdev instead"); > > > } > > > if (node->has_memdev) { > > > Object *o; > > > diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi > > > index 45c5795..73f99d4 100644 > > > --- a/qemu-deprecated.texi > > > +++ b/qemu-deprecated.texi > > > @@ -60,6 +60,20 @@ Support for invalid topologies will be removed, the user must ensure > > > topologies described with -smp include all possible cpus, i.e. > > > @math{@var{sockets} * @var{cores} * @var{threads} = @var{maxcpus}}. > > > > > > +@subsection -numa node,mem=@var{size} (since 4.0) > > > + > > > +The parameter @option{mem} of @option{-numa node} is used to assign a part of > > > +guest RAM to a NUMA node. But when using it, it's impossible to manage specified > > > +size on the host side (like bind it to a host node, setting bind policy, ...), > > > +so guest end-ups with the fake NUMA configuration with suboptiomal performance. > > > +However since 2014 there is an alternative way to assign RAM to a NUMA node > > > +using parameter @option{memdev}, which does the same as @option{mem} and has > > > +an ability to actualy manage node RAM on the host side. Use parameter > > > +@option{memdev} with @var{memory-backend-ram} backend as an replacement for > > > +parameter @option{mem} to achieve the same fake NUMA effect or a properly > > > +configured @var{memory-backend-file} backend to actually benefit from NUMA > > > +configuration. > > > + > > > @section QEMU Machine Protocol (QMP) commands > > > > > > @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) > > > -- > > > 2.7.4 > > > > > > -- > > > libvir-list mailing list > > > libvir-list(a)redhat.com > > > https://www.redhat.com/mailman/listinfo/libvir-list > > > > Regards, > > Daniel > -- Dr. David Alan Gilbert / dgilbert(a)redhat.com / Manchester, UK