qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: "Wang, Lei" <lei4.wang@intel.com>,
	qemu-devel@nongnu.org,
	"Maciej S . Szmigiero" <mail@maciej.szmigiero.name>
Subject: Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters
Date: Fri, 12 Jul 2024 11:37:47 -0400	[thread overview]
Message-ID: <ZpFNywuZ3Z-OPH9X@x1n> (raw)
In-Reply-To: <875xtaeq5p.fsf@suse.de>

On Fri, Jul 12, 2024 at 09:44:02AM -0300, Fabiano Rosas wrote:
> Do you have a reference for that kubevirt issue I could look at? It
> maybe interesting to investigate further. Where's the throttling coming
> from? And doesn't less vcpu time imply less dirtying and therefore
> faster convergence?

Sorry I don't have a link on hand.. sometimes it's not about converge, it's
about impacting the guest workload too much without intention which is not
wanted, especially if on a public cloud.

It's understandable to me since they're under the same cgroup with
throttled cpu resources applie to QEMU+Libvirt processes as a whole,
probably based on N_VCPUS with some tiny extra room for other stuff.

For example, I remember they also hit other threads content with the vcpu
threads like the block layer thread pools.

It's a separate issue here when talking about locked_vm, as kubevirt
probably need to figure out a way to say "these are mgmt threads, and those
are vcpu threads", because mgmt threads can take quite some cpu resources
sometimes and it's not avoidable.  Page pinning will be another story, as
in many cases pinning should not be required, except VFIO, zerocopy and
other special stuff.

-- 
Peter Xu



  reply	other threads:[~2024-07-12 15:38 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20 21:21 [RFC PATCH 0/7] migration/multifd: Introduce storage slots Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 1/7] migration/multifd: Reduce access to p->pages Fabiano Rosas
2024-06-21 14:42   ` Peter Xu
2024-06-20 21:21 ` [RFC PATCH 2/7] migration/multifd: Pass in MultiFDPages_t to file_write_ramblock_iov Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 3/7] migration/multifd: Replace p->pages with an opaque pointer Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 4/7] migration/multifd: Move pages accounting into multifd_send_zero_page_detect() Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 5/7] migration/multifd: Isolate ram pages packet data Fabiano Rosas
2024-07-19 14:40   ` Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters Fabiano Rosas
2024-06-27  3:27   ` Wang, Lei
2024-06-27 14:40     ` Peter Xu
2024-06-27 15:17       ` Peter Xu
2024-07-10 16:10       ` Fabiano Rosas
2024-07-10 19:10         ` Peter Xu
2024-07-10 20:16           ` Fabiano Rosas
2024-07-10 21:55             ` Peter Xu
2024-07-11 14:12               ` Fabiano Rosas
2024-07-11 16:11                 ` Peter Xu
2024-07-11 19:37                   ` Fabiano Rosas
2024-07-11 20:27                     ` Peter Xu
2024-07-11 21:12                       ` Fabiano Rosas
2024-07-11 22:06                         ` Peter Xu
2024-07-12 12:44                           ` Fabiano Rosas
2024-07-12 15:37                             ` Peter Xu [this message]
2024-07-18 19:39                   ` Fabiano Rosas
2024-07-18 21:12                     ` Peter Xu
2024-07-18 21:27                       ` Fabiano Rosas
2024-07-18 21:52                         ` Peter Xu
2024-07-18 22:32                           ` Fabiano Rosas
2024-07-19 14:04                             ` Peter Xu
2024-07-19 16:54                               ` Fabiano Rosas
2024-07-19 17:58                                 ` Peter Xu
2024-07-19 21:30                                   ` Fabiano Rosas
2024-07-16 20:10             ` Maciej S. Szmigiero
2024-07-17 19:00               ` Peter Xu
2024-07-17 21:07                 ` Maciej S. Szmigiero
2024-07-17 21:30                   ` Peter Xu
2024-06-20 21:21 ` [RFC PATCH 7/7] migration/multifd: Hide multifd slots implementation Fabiano Rosas
2024-06-21 14:44 ` [RFC PATCH 0/7] migration/multifd: Introduce storage slots Maciej S. Szmigiero
2024-06-21 15:04   ` Fabiano Rosas
2024-06-21 15:31     ` Maciej S. Szmigiero
2024-06-21 15:56       ` Peter Xu
2024-06-21 17:40         ` Maciej S. Szmigiero
2024-06-21 20:54           ` Peter Xu
2024-06-23 20:25             ` Maciej S. Szmigiero
2024-06-23 20:45               ` Peter Xu

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=ZpFNywuZ3Z-OPH9X@x1n \
    --to=peterx@redhat.com \
    --cc=farosas@suse.de \
    --cc=lei4.wang@intel.com \
    --cc=mail@maciej.szmigiero.name \
    --cc=qemu-devel@nongnu.org \
    /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).