[libvirt] Paradox cpu topology in capabilities outputs

乔立勇(Eli Qiao) qiaoliyong at gmail.com
Wed Jan 11 09:59:31 UTC 2017


2017-01-11 17:38 GMT+08:00 Daniel P. Berrange <berrange at redhat.com>:

> On Wed, Jan 11, 2017 at 06:52:45AM +0000, Qiao, Liyong wrote:
> > Hi,
> >
> > I observe that virsh capabilities give wrong cpu topology on a multiple
> sockets host
> >
> > taget at jfz1r04h13:~/libvirt$ lscpu
> > Architecture:          x86_64
> > CPU op-mode(s):        32-bit, 64-bit
> > Byte Order:            Little Endian
> > CPU(s):                72
> > On-line CPU(s) list:   0-71
> > Thread(s) per core:    2
> > Core(s) per socket:    18
> > Socket(s):             2 <------------------------
> > NUMA node(s):          2
> > Vendor ID:             GenuineIntel
> > CPU family:            6
> > Model:                 63
> > Model name:            Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
> > Stepping:              2
> > CPU MHz:               1201.660
> > CPU max MHz:           3600.0000
> > CPU min MHz:           1200.0000
> > BogoMIPS:              4590.78
> > Virtualization:        VT-x
> > L1d cache:             32K
> > L1i cache:             32K
> > L2 cache:              256K
> > L3 cache:              46080K
> > NUMA node0 CPU(s):     0-17,36-53
> > NUMA node1 CPU(s):     18-35,54-71
> >
> > But output of virsh capabilities only gives.
> >
> > <topology sockets='1' cores='18' threads='2'/>
>
> The 'sockets' value is basically "sockets-per-NUMA-node".
>
> >
> > looking into code and got this:
> > https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virhostcpu.c;h=
> f29f3122acee018b9fd7dca06fd7ae1fc118b210;hb=HEAD#l703
> >
> > should we change it into
> >
> > 704<https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/
> util/virhostcpu.c;h=f29f3122acee018b9fd7dca06fd7ae1fc118b210;hb=HEAD#l704>
>            *sockets  += nodesockets;
> >
> >
> > This also affect nodeinfo.sockets.
>
> BOth the <topology> summary and nodeinfo data is really a broken
> design as it can't cope with asymetric topologies. We recommend
> apps to completely ignore this data, and instead look at the fine
> grained topology info in the capabilities:
>
>     <topology>
>       <cells num='2'>
>         <cell id='0'>
>           ...
>           <cpus num='6'>
>             <cpu id='0' socket_id='0' core_id='0' siblings='0'/>
>             <cpu id='1' socket_id='0' core_id='2' siblings='1'/>
>             <cpu id='2' socket_id='0' core_id='4' siblings='2'/>
>             <cpu id='6' socket_id='0' core_id='1' siblings='6'/>
>             <cpu id='7' socket_id='0' core_id='3' siblings='7'/>
>             <cpu id='8' socket_id='0' core_id='5' siblings='8'/>
>           </cpus>
>         </cell>
>         ...
>       </cells>
>     </topology>
>
>
>
Thanks Daniel, it's really good to know this.


>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/
> :|
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>



-- 
天涯无处不重逢
a leaf duckweed belongs to the sea , where not to meet in life
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170111/56db879f/attachment-0001.htm>


More information about the libvir-list mailing list