From: Zhao Liu <zhao1.liu@intel.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Anthony Harivel <aharivel@redhat.com>,
pbonzini@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org,
vchundur@redhat.com, rjarry@redhat.com
Subject: Re: [PATCH v5 3/3] Add support for RAPL MSRs in KVM/Qemu
Date: Wed, 17 Apr 2024 23:13:52 +0800 [thread overview]
Message-ID: <Zh/nMFpfKIORYW97@intel.com> (raw)
In-Reply-To: <Zh_AF3YfiZeIAkCU@redhat.com>
Hi Daniel,
On Wed, Apr 17, 2024 at 01:27:03PM +0100, Daniel P. Berrangé wrote:
> Date: Wed, 17 Apr 2024 13:27:03 +0100
> From: "Daniel P. Berrangé" <berrange@redhat.com>
> Subject: Re: [PATCH v5 3/3] Add support for RAPL MSRs in KVM/Qemu
>
> On Wed, Apr 17, 2024 at 06:07:02PM +0800, Zhao Liu wrote:
> > Hi Anthony,
> >
> > May I ask what your usage scenario is? Is it to measure Guest's energy
> > consumption and to charged per watt consumed? ;-)
> >
> > On Thu, Apr 11, 2024 at 02:14:34PM +0200, Anthony Harivel wrote:
> > > Date: Thu, 11 Apr 2024 14:14:34 +0200
> > > From: Anthony Harivel <aharivel@redhat.com>
> > > Subject: [PATCH v5 3/3] Add support for RAPL MSRs in KVM/Qemu
> > >
> > > Starting with the "Sandy Bridge" generation, Intel CPUs provide a RAPL
> > > interface (Running Average Power Limit) for advertising the accumulated
> > > energy consumption of various power domains (e.g. CPU packages, DRAM,
> > > etc.).
> > >
> > > The consumption is reported via MSRs (model specific registers) like
> > > MSR_PKG_ENERGY_STATUS for the CPU package power domain. These MSRs are
> > > 64 bits registers that represent the accumulated energy consumption in
> > > micro Joules. They are updated by microcode every ~1ms.
> >
> > What is your current target platform?
>
> I think we can assume /all/ future CPUs are conceptially in scope
> for this.
>
> The use case is to allow guest owners to monitor the power consumption
> of their workloads, so they can take steps to optimize their guest VM
> workloads to reduce power consumed.
Thanks for the explanation!
> > On future Xeon platforms (EMR and beyond) RAPL will support TPMI (an MMIO
> > interface) and the TPMI based RAPL will be preferred in the future as
> > well:
>
> Is the MSR based interface likely to be removed in future silicon,
> or it will be remain for back compat ?
For Xeon, GNR will have both TMPI & MSR RAPL, but eventually MSR RAPL
will be removed. Therefore, if RAPL support is desired for all future
Xeons, then it's necessary to consider TMPI as the next plan.
Alternatively, the whole RAPL scope can be split into rapl-msr and
rapl-tpmi features.
> > * TPMI doc: https://github.com/intel/tpmi_power_management
> > * TPMI based RAPL driver: drivers/powercap/intel_rapl_tpmi.c
> >
Regards,
Zhao
next prev parent reply other threads:[~2024-04-17 15:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 12:14 [PATCH v5 0/3] Add support for the RAPL MSRs series Anthony Harivel
2024-04-11 12:14 ` [PATCH v5 1/3] qio: add support for SO_PEERCRED for socket channel Anthony Harivel
2024-04-12 10:58 ` Paolo Bonzini
2024-04-11 12:14 ` [PATCH v5 2/3] tools: build qemu-vmsr-helper Anthony Harivel
2024-04-11 12:14 ` [PATCH v5 3/3] Add support for RAPL MSRs in KVM/Qemu Anthony Harivel
2024-04-17 10:07 ` Zhao Liu
2024-04-17 12:27 ` Daniel P. Berrangé
2024-04-17 15:13 ` Zhao Liu [this message]
2024-04-18 8:33 ` Anthony Harivel
2024-04-18 10:52 ` Anthony Harivel
2024-04-19 15:47 ` Zhao Liu
2024-04-17 17:55 ` Daniel P. Berrangé
2024-04-18 16:42 ` Daniel P. Berrangé
2024-04-18 16:57 ` Anthony Harivel
2024-04-25 15:34 ` Anthony Harivel
2024-04-25 15:42 ` Daniel P. Berrangé
2024-04-26 8:36 ` Anthony Harivel
2024-05-06 9:41 ` Anthony Harivel
2024-04-12 10:57 ` [PATCH v5 0/3] Add support for the RAPL MSRs series Paolo Bonzini
2024-04-17 17:58 ` Daniel P. Berrangé
2024-04-19 17:30 ` Paolo Bonzini
2024-04-17 17:23 ` Daniel P. Berrangé
2024-04-18 8:08 ` Anthony Harivel
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=Zh/nMFpfKIORYW97@intel.com \
--to=zhao1.liu@intel.com \
--cc=aharivel@redhat.com \
--cc=berrange@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjarry@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).