qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.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 v6 0/3] Add support for the RAPL MSRs series
Date: Tue, 22 Oct 2024 14:46:15 +0200	[thread overview]
Message-ID: <20241022144615.203cf0da@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <ZxJbtkMO1QcoiqVn@redhat.com>

On Fri, 18 Oct 2024 13:59:34 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Fri, Oct 18, 2024 at 02:25:26PM +0200, Igor Mammedov wrote:
> > On Wed, 16 Oct 2024 14:56:39 +0200
> > "Anthony Harivel" <aharivel@redhat.com> wrote:
[...]

> > 
> > This also leads to a question, if we should account for
> > not VCPU threads at all. Looking at real hardware, those
> > MSRs return power usage of CPUs only, and they do not
> > return consumption from auxiliary system components
> > (io/memory/...). One can consider non VCPU threads in QEMU
> > as auxiliary components, so we probably should not to
> > account for them at all when modeling the same hw feature.
> > (aka be consistent with what real hw does).  
> 
> I understand your POV, but I think that would be a mistake,
> and would undermine the usefulness of the feature.
> 
> The deployment model has a cluster of hosts and guests, all
> belonging to the same user. The user goal is to measure host
> power consumption imposed by the guest, and dynamically adjust
> guest workloads in order to minimize power consumption of the
> host.

For cloud use-case, host side is likely in a better position
to accomplish the task of saving power by migrating VM to
another socket/host to compact idle load. (I've found at least 1
kubernetis tool[1], which does energy monitoring). Perhaps there
are schedulers out there that do that using its data.

> The guest workloads can impose non-negligble power consumption
> loads on non-vCPU threads in QEMU. Without that accounted for,
> any adjustments will be working from (sometimes very) inaccurate
> data.

Perhaps adding one or several energy sensors (ex: some i2c ones),
would let us provide auxiliary threads consumption to guest, and
even make it more granular if necessary (incl. vhost user/out of
process device models or pass-through devices if they have PMU).
It would be better than further muddling vCPUs consumption
estimates with something that doesn't belong there.

> IOW, I think it is right to include non-vCPU threads usage in
> the reported info, as it is still fundamentally part of the
> load that the guest imposes on host pCPUs it is permitted to
> run on.


From what I've read, process energy usage done via RAPL is not
exactly accurate. But there are monitoring tools out there that
use RAPL and other sources to make energy consumption monitoring
more reliable.

Reinventing that wheel and pulling all of the nuances of process
power monitoring inside of QEMU process, needlessly complicates it.
Maybe we should reuse one of existing tools and channel its data
through appropriate QEMU channels (RAPL/emulated PMU counters/...).

Implementing RAPL in pure form though looks fine to me,
so the same tools could use it the same way as on the host
if needed without VM specific quirks.

1) https://github.com/sustainable-computing-io/kepler

> With regards,
> Daniel



  reply	other threads:[~2024-10-22 12:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22 15:34 [PATCH v6 0/3] Add support for the RAPL MSRs series Anthony Harivel
2024-05-22 15:34 ` [PATCH v6 1/3] qio: add support for SO_PEERCRED for socket channel Anthony Harivel
2024-05-22 15:34 ` [PATCH v6 2/3] tools: build qemu-vmsr-helper Anthony Harivel
2024-05-22 15:34 ` [PATCH v6 3/3] Add support for RAPL MSRs in KVM/Qemu Anthony Harivel
2024-10-16 12:17   ` Igor Mammedov
2024-10-16 13:04     ` Anthony Harivel
2024-06-26 14:34 ` [PATCH v6 0/3] Add support for the RAPL MSRs series Anthony Harivel
2024-10-16 11:52 ` Igor Mammedov
2024-10-16 12:56   ` Anthony Harivel
2024-10-18 12:25     ` Igor Mammedov
2024-10-18 12:59       ` Daniel P. Berrangé
2024-10-22 12:46         ` Igor Mammedov [this message]
2024-10-22 13:15           ` Daniel P. Berrangé
2024-10-22 14:16             ` Anthony Harivel
2024-10-22 14:29               ` Daniel P. Berrangé
2024-10-22 14:40                 ` Anthony Harivel
2024-11-01 15:09               ` Igor Mammedov
2024-11-02  9:32                 ` Anthony Harivel
2024-11-04  9:49                   ` Igor Mammedov
2024-11-05  7:11                     ` Christian Horn
2024-11-05 12:19                       ` Igor Mammedov
2024-11-06  3:14                         ` Christian Horn
2024-10-22 15:35             ` Igor Mammedov
2024-10-22 13:49       ` Anthony Harivel
2024-11-04  9:40         ` Igor Mammedov

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=20241022144615.203cf0da@imammedo.users.ipa.redhat.com \
    --to=imammedo@redhat.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 NNTP newsgroup(s).