Re: [PATCH] Extend l3 cache to nodeinfo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux