On Wed, Jan 11, 2017 at 10:08:25AM +0000, Daniel P. Berrange wrote:
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. >
Also don't forget you can have multiple NUMA nodes in one socket. Be it for example AMD Bulldozer and similar or kernel's fake NUMA.
> > 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).
I like your idea better. It doesn't have to be necessarily flat (you can group some parts of it), but I don't really care that much about how flat it is. I like it better because you can represent any split/shared caches. And being prepared for any cache layout is what I cared about.
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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
