From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Anthony Harivel <aharivel@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:04:41 +0000 [thread overview]
Message-ID: <ZfGIScbYp3htVRMi@redhat.com> (raw)
In-Reply-To: <CZSKAAQ3HE0Q.32DYA8Y3PX16V@fedora>
On Wed, Mar 13, 2024 at 11:48:19AM +0100, Anthony Harivel wrote:
> 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 ?
You don't need to access it via the /node/ hierarchy
The canonical path for CPUs would be
/sys/devices/system/cpu/cpuNNN/topology
The core_cpus_list file is giving you hyper-thread siblings within
a core, which I don't think is what you want.
If you're after discrete physical packages, then 'package_cpus_list'
gives you all CPUs within a physical socket (package) I believe.
> 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
That won't cope with asymmetrical CPU configurations, so I think it
is preferrable to read the info from sysfs.
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 :|
next prev parent reply other threads:[~2024-03-13 11:05 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
2024-03-13 11:04 ` Daniel P. Berrangé [this message]
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=ZfGIScbYp3htVRMi@redhat.com \
--to=berrange@redhat.com \
--cc=aharivel@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.