On Wed, Jan 11, 2017 at 05:48:34PM +0800, 乔立勇 wrote: > 2017-01-11 17:34 GMT+08:00 Daniel P. Berrange <berrange@xxxxxxxxxx>: > > > On Wed, Jan 11, 2017 at 09:31:04AM +0000, Qiao, Liyong wrote: > > > Hi Daniel, > > > > > > I agree that to expose othe level cache but the only can be tuned > > (allocation). If we expose such kinds of information, the host should have > > ability to control such kinds of resources. > > > > > > In another thread, Martin told that there are cases which multiple > > sockets may has different values, I kinds of agree(but I don’t see that > > case), I agree to expose cache per socket, just wonder if > > > > > > cell == socket in libvirt? In my environment, I can see all socket_id in > > a cell are the same, wonder if I can extend cache information to cell node? > > > > No, cell == NUMA node. There can be multiple sockets per NUMA node. If > > you > > see multiple CPUs with the same socket_id, this indicates they are cores > > within the same CPU socket. > > > > > > Hi Daniel, > > This's Eli again(gmail is better with formate) > > thanks for your reply, > > hmm... if so, we want to expose cache information though capabilities, we > need another topology to expose all sockets > > such as > > <host> > <uuid>f481c038-bb08-42e1-aa5f-f008a27e7050</uuid> > <cpu> > ... > <cache> > <sockets num = '2'> > <socket id=0> > <l3_cache unit='KiB' > support_allocation='yes'>56320</l3_cache> > <l2_cache unit='KiB'''>256</l2_cache> > </socket> > <socket id=1> > <l3_cache unit='KiB' > support_allocation='yes'>56320</l3_cache> > <l2_cache unit='KiB'''>256</l2_cache> > </socket> > </sockets> > </cache> > </cpu> That's one possible option - I suggested another here: https://www.redhat.com/archives/libvir-list/2017-January/msg00489.html I'm not sure whether it is better to do a nested structure as you have, or a flat structure as I did. In particular I'm wondering if we can assume caches are strictly hierarchical (in which case nested will work), or whether there can be sharing across branches (in which case flat will be needed). 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
