于 2011年08月19日 16:09, Bharata B Rao 写道: > On Fri, Aug 19, 2011 at 12:55 PM, Osier Yang <jy...@redhat.com> wrote: >> 于 2011年08月19日 14:35, Bharata B Rao 写道: >>> How about something like this ? (OPTION 1) >>> >>> <cpu> >>> ... >>> <numa nodeid='node' cpus='cpu[-cpu]' mem='size'> >>> ... >>> </cpu> >>> >> Libvirt already supported NUMA setting (both cpu and memory) >> on host yet, but yes, nothing for NUMA setting inside guest yet. >> >> We have talked once about the XML when adding the support >> for numa memory setting on host. And finally choosed to introduce >> new XML node for it with considering to add support for NUMA >> setting inside guest one day. The XML is: >> >> <numatune> >> <memory mode="strict" nodeset="1-4,^3"/> >> </numatune> > But this only specifies the host NUMA policy that should be used for > guest VM processes.
Yes. >> So, personlly, I think the new XML should be inside "<numatune>" >> as a child node. >> >> >>> And we could specify multiple such lines, one for each node. >>> >>> -numa and -smp options in qemu do not work all that well since they >>> are parsed independent of each other and one could specify a cpu set >>> with -numa option that is incompatible with sockets,cores and threads >>> specified on -smp option. This should be fixed in qemu, but given that >>> such a problem has been observed, should libvirt tie the specification >>> of numa and smp (sockets,threads,cores) together so that one is forced >>> to specify only valid combinations of nodes and cpus in libvirt ? >>> >>> May be something like this: (OPTION 2) >>> >>> <cpu> >>> ... >>> <topology sockets='1' cores='2' threads='1' nodeid='0' cpus='0-1' >>> mem='size'> >>> <topology sockets='1' cores='2' threads='1' nodeid='1' cpus='2-3' >>> mem='size'> >>> ... >>> </cpu >> This will cause we have 3 places for NUMA, >> one is <numatune>, > As I observed above, this controls the NUMA policy of the guest VM > threads on host. Yes, I known your meaning. >> the other is "<vcpu>", > vcpu/cpuset specifies how vcpu threads should be pinned on host. > >> and this one. > I think what we are addressing here is a bit different from the above > two. Here we are actually trying to _define_ the NUMA topology of the > guest, while via other capabilites (numatune, vcpu) we only control > the cpu and memory bindings of vcpu threads on host. > > Hence I am not sure if if <numatune> is the right place for defining > host NUMA topology which btw should be independent of the host > topology. Maybe something like: <numatune> <guest> ...... </guest> </numatune> > Thanks for your response. > > Regards, > Bharata. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
