public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Anthony Harivel" <aharivel@redhat.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>
Cc: <kvm@vger.kernel.org>, <rjarry@redhat.com>,
	"Christophe Fontaine" <cfontain@redhat.com>,
	<xiaoyao.li@intel.com>
Subject: Re: [RFC] KVM: x86: Give host userspace control for MSR_RAPL_POWER_UNIT and MSR_PKG_POWER_STATUS
Date: Mon, 23 Jan 2023 13:43:51 +0100	[thread overview]
Message-ID: <CPZKUO224B8I.3UNLB18V94IF2@fedora> (raw)
In-Reply-To: <CABgObfb4uYa817tG9Q8vS-O0XVqom1CRia+g=hSuAYWOB2+xHQ@mail.gmail.com>

On Fri Jan 20, 2023 at 5:57 PM CET, Paolo Bonzini wrote:
> On Fri, Jan 20, 2023 at 5:48 PM Anthony Harivel <aharivel@redhat.com> wrote:
> > So I'm wondering if the contexts switching (KVM->userpace->KVM) to
> > update all MSRs will cause performance issues?
>
> How often do you anticipate them to be read by the guest?
>

The more often we can update the register, the more accurate we can be.
Not accurate in terms of consumption but in terms of time. Imagine
a burst of data that needs to be processed by a vCPU every 100ms, if we
update the registers every seconds we will never target which burst is
consuming the most. It's a total made up example but it gives an idea.
But we have to keep in mind that those energy counters are updated at
the average rate of ~1ms.


> > What I'm pretty sure is that updating the values should be done
> > separately from the callback that consume the value. This would ensure
> > the consistency of the values.
> >
> > In the hypothesis those MSRs are handled within KVM, we can read MSRs
> > with rdmsrl_safe() but how can we get the percentage of CPU used by Qemu
> > to get a proportional value of the counter?
>
> If you are okay with only counting the time spent in the guest, i.e.
> not in QEMU, you can snapshot the energy value when the vCPU starts
> (kvm_arch_vcpu_load, kvm_sched_in) and update it when the vCPU stops
> (kvm_sched_out, kvm_get_msr and post_kvm_run_save).
>
> Paolo

I think this is great idea and would have worked perfectly if we were
able to get the individual core power consumption. However we are down
to, in the best case, to the power consumption of all Cores per package
(PP0/Core power plane). And in the server CPU Family (i.e Xeon), we only
have the Package power plane which include consumption of all cores in
the package plus the uncore power consumption (i.e. last level of caches
and memory controller; consumption of DRAM memory not included). So
depending on the workload of all the cores and the uses of the uncore
part, the energy counter of the package is increasing more or less
quicker between samples of the same period.

Anthony


      reply	other threads:[~2023-01-23 12:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18 14:21 [RFC] KVM: x86: Give host userspace control for MSR_RAPL_POWER_UNIT and MSR_PKG_POWER_STATUS Anthony Harivel
2023-01-19  5:57 ` Xiaoyao Li
2023-01-20  8:59   ` Anthony Harivel
2023-01-19 23:27 ` Paolo Bonzini
2023-01-20 16:47   ` Anthony Harivel
2023-01-20 16:57     ` Paolo Bonzini
2023-01-23 12:43       ` Anthony Harivel [this message]

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=CPZKUO224B8I.3UNLB18V94IF2@fedora \
    --to=aharivel@redhat.com \
    --cc=cfontain@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rjarry@redhat.com \
    --cc=xiaoyao.li@intel.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