[libvirt] [PATCH] Extend l3 cache to nodeinfo

[Martin Kletzander]

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 at redhat.com>:
>>
>> > 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 at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170111/e27c6cd1/attachment-0001.sig>