Hi Zhao, Daniel,
Zhao Liu, Apr 17, 2024 at 17:13: > 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é" <berra...@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 <ahari...@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! > Thanks Daniel for stepping in on 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. > I'm aware of the MSR/TPMI RAPL that will appear in the future, and I would like to share my perspective on that. Firstly, we can safely assume that it will take years before all server hardware is transitioned to the new GNR (or future XEON without RAPL MSR). It may be around 2024 when these features could be integrated into QEMU. While the adoption of this feature might take some time, I'm optimistic that once it's implemented, people will finally have the tools to optimize workloads inside VMs and start reducing power consumption. Secondly, the second-hand server market is substantial. This means that with the Virtual RAPL MSR, all XEON processors starting from Sandy Bridge (2012!) will have the potential for software optimization. Making the most of existing resources is essential for sustainability. Lastly, when the TPMI becomes available in hardware in the future, the RAPL interface and ratio calculation will remain the same, with only the method of obtaining host values changing. This transition should be manageable. Regards, Anthony
