From: "Anthony Harivel" <aharivel@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: <pbonzini@redhat.com>, <mtosatti@redhat.com>,
<qemu-devel@nongnu.org>, <vchundur@redhat.com>
Subject: Re: [PATCH v3 3/3] Add support for RAPL MSRs in KVM/Qemu
Date: Wed, 13 Mar 2024 11:48:19 +0100 [thread overview]
Message-ID: <CZSKAAQ3HE0Q.32DYA8Y3PX16V@fedora> (raw)
In-Reply-To: <ZfB5eBwWXL45sN_K@redhat.com>
Hi Daniel,
Daniel P. Berrangé, Mar 12, 2024 at 16:49:
> The point still stands though. NUMA node ID numbers are not
> guaranteed to be the same as socket ID numbers. Very often
> then will be the same (which makes it annoying to test as it
> is easy to not realize the difference), but we can't rely on
> that.
>
> > I'm using functions of libnuma to populate the maxpkgs of the host.
> > I tested this on different Intel CPU with multiple packages and this
> > has always returned the good number of packages. A false positive ?
>
> maxpkgs comes from vmsr_get_max_physical_package() which you're
> reading from sysfs, rather than libnuma.
>
> > So here I'm checking if the thread has run on the package number 'i'.
> > I populate 'numa_node_id' with numa_node_of_cpu().
> >
> > I did not wanted to reinvent the wheel and the only lib that was talking
> > about "node" was libnuma.
>
> I'm not actually convinced we need to use libnuma at all. IIUC, you're
> just trying to track all CPUs within the same physical socket (package).
> I don't think we need to care about NUMA nodes to do that tracking.
>
Alright, having a deeper look I'm actually using NUMA for 2 info:
- How many cpu per Package: this helps me calculate the ratio.
- To whom package the cpu belongs: to calculate the ratio with the right
package energy counter.
Without libnuma, I'm bit confused on how to handle this.
Should I parse /sys/bus/node/devices/node* to know how many packages ?
Should I parse /sys/bus/node/devices/node0/cpu0/topology/core_cpus_list
to handle which cpu belongs to which package ?
Would that be too cumbusome for the user to enter the detail about how
many packages and how many cpu per pakages ?
i.e:
-kvm,rapl=true,maxpkgs=2,cpupkgs=8,rapl-helper-socket=/path/sock.sock
> > Maybe I'm wrong assuming that a "node" (defined as an area where all
> > memory has the same speed as seen from a particular CPU) could lead me
> > to the packages number ?
>
> Historically you could have multiple sockets in the same NUMA node
> ie a m:1 mapping.
>
> These days with AMD sockets, you can have 1 socket compromising
> many NUMA nodes, as individual dies within a socket are each their
> own NUMA node. So a 1:m mapping
>
> On Intel I think it is still typical to have 1 socket per numa
> node, but again I don't think we can rely on that 1:1 mapping.
>
> Fortunately I don't think it matters, since it looks like you
> don't really need to track NUMA nodes, only sockets (phnysical
> package IDs)
>
Very informative, thanks !
> With regards,
> Daniel
> --
> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o- https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Regards,
Anthony
next prev parent reply other threads:[~2024-03-13 10:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 7:22 [PATCH v3 0/3] Add support for the RAPL MSRs series Anthony Harivel
2024-01-25 7:22 ` [PATCH v3 1/3] qio: add support for SO_PEERCRED for socket channel Anthony Harivel
2024-01-25 16:37 ` Daniel P. Berrangé
2024-01-29 19:25 ` Paolo Bonzini
2024-01-29 19:30 ` Daniel P. Berrangé
2024-01-25 7:22 ` [PATCH v3 2/3] tools: build qemu-vmsr-helper Anthony Harivel
2024-01-29 18:53 ` Daniel P. Berrangé
2024-01-29 19:33 ` Paolo Bonzini
2024-01-29 19:45 ` Daniel P. Berrangé
2024-01-29 19:53 ` Daniel P. Berrangé
2024-01-29 20:21 ` Paolo Bonzini
2024-02-21 13:19 ` Anthony Harivel
2024-02-21 13:47 ` Daniel P. Berrangé
2024-02-21 13:52 ` Anthony Harivel
2024-03-01 11:08 ` Anthony Harivel
2024-01-25 7:22 ` [PATCH v3 3/3] Add support for RAPL MSRs in KVM/Qemu Anthony Harivel
2024-01-29 19:29 ` Daniel P. Berrangé
2024-02-20 14:00 ` Anthony Harivel
2024-02-20 15:00 ` Daniel P. Berrangé
2024-03-05 14:58 ` Anthony Harivel
2024-01-30 9:13 ` Daniel P. Berrangé
2024-03-04 14:41 ` Anthony Harivel
2024-03-04 14:48 ` Daniel P. Berrangé
2024-03-05 13:25 ` Anthony Harivel
2024-03-05 13:57 ` Daniel P. Berrangé
2024-01-30 9:39 ` Daniel P. Berrangé
2024-03-12 11:21 ` Anthony Harivel
2024-03-12 15:49 ` Daniel P. Berrangé
2024-03-13 10:48 ` Anthony Harivel [this message]
2024-03-13 11:04 ` Daniel P. Berrangé
2024-03-14 8:26 ` Anthony Harivel
2024-03-14 8:55 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CZSKAAQ3HE0Q.32DYA8Y3PX16V@fedora \
--to=aharivel@redhat.com \
--cc=berrange@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vchundur@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.