Re: [PATCH v6 0/3] Add support for the RAPL MSRs series

[Christian Horn <chorn@fluxcoil.net>]

Hi all,

some thoughts:

- I vote for making the metrics as much as possible in the guest available
  as on the host.  Allows cascading, and having in-guest-monitoring working
  like on bare metal.
- As result, really just plain vCPU consumption would be made available
  in the guest as rapl-core.  If the host can at some point understand
  guests GPU, or I/O consumption, better hand that in separately.
- Having in mind that we will also need this for other architectures, 
  at least aarch64.  RAPL comes from x86, rather than extending that
  to also do I/O or such, we might aim at an interface which will also
  work for aarch64.
- Bigger scope will be to look at the consumption of multiple systems, for
  that we will need to move the metrics to network eventually, changing
  from MSR or such mechanisms.
- For reading the metrics in the guest, I was tempted to suggest PCP with
  pmda-denki to cover RAPL, but it's right now just reading /sysfs, not
  MSR's.  pmda-lmsensors for further sensors offered on various systems,
  and pmda-openmetrics for covering anything appearing somewhere on
  /sysfs as a number.
 

> > Not that I disagree with all you said, to the contrary, but the amount 
> > of change is quite significant and it would be very annoying if results 
> > of this work doesn't make upstream because of Y & X.
> 
> split frontend/backend design is established pattern in QEMU, so I'm not
> suggesting anything revolutionary (probability that anyone would object
> to it is very low).
> 
> sending an RFC can serve as a starting point for discussion.  

+1,
Christian