qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Yong Huang <yong.huang@smartx.com>
Cc: qemu-devel@nongnu.org, "Fabiano Rosas" <farosas@suse.de>,
	"Eric Blake" <eblake@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH RESEND RFC 03/10] qapi/migration: Introduce periodic CPU throttling parameters
Date: Tue, 10 Sep 2024 09:56:07 -0400	[thread overview]
Message-ID: <ZuBP90uSWiJWXTgQ@x1n> (raw)
In-Reply-To: <CAK9dgma+kmV=sXPu-RUnT8mkQmRUJXRRkiDXfFDoT+6JBu-nHw@mail.gmail.com>

On Tue, Sep 10, 2024 at 01:47:04PM +0800, Yong Huang wrote:
> On Tue, Sep 10, 2024 at 5:30 AM Peter Xu <peterx@redhat.com> wrote:
> 
> > On Mon, Sep 09, 2024 at 10:25:36PM +0800, Hyman Huang wrote:
> > > To activate the periodic CPU throttleing feature, introduce
> > > the cpu-periodic-throttle.
> > >
> > > To control the frequency of throttling, introduce the
> > > cpu-periodic-throttle-interval.
> > >
> > > Signed-off-by: Hyman Huang <yong.huang@smartx.com>
> >
> > Considering that I would still suggest postcopy over auto-converge, IMO we
> >
> 
> We are considering the hybrid of precopy and postcopy in fact, and i
> entirely agree with what you are saying: postcopy migration is an
> alternative
> solution to deal with migrations that refuse to converge, or take too long
> to converge. But enabling this feature may not be easy in production since
> the
> recovery requires upper apps to interface, the hugepages and spdk/dpdk

Libvirt should support recovery, while vhost-user should also be supported
in general by both qemu/libvirt.  Huge page is indeed still the issue,
though.

> scenarios also need to be considered and re-test.
> Considering auto-converge is the main policy in the industry, the
> optimization
> may still make sense. We would like to try to optimize the auto-converge in
> huge
> VM case and, IMHO, it doesn't conflict with postcopy.

Yeah, that's OK.

> 
> 
> > should be cautious on adding more QMP interfaces on top of auto-converge,
> > because that means more maintenance burden everywhere.. and it's against
> > our goal to provide, hopefully, one solution for the long term for
> > convergence issues.
> >
> > Postcopy has a major issue with VFIO, but auto converge isn't anything
> > better from that regard.. as we can't yet throttle a device so far anyway.
> > Throttling of DMA probably means DMA faults, then postcopy might be doable
> > too.  Meanwhile we're looking at working out 1G postcopy at some point.
> >
> > So I wonder whether we can make any further optmization for auto-converge
> > (if we still really want that..) to be at least transparent, so that they
> >
> 
> Thanks for the advice and of course yes.
> So, at first, We'll try to avoid adding the new periodic throttle parameter
> and make it be transparent ?

That'll be my take on this, so we can keep relatively focused for hopefully
all migration developers around QEMU in the near future.  I wonder this
could be a good measure so we at least try to reduce part of the burden.

I don't think it's a published rule, it's just something I thought about
when glancing your series.  So feel free to share your thoughts.  Btw I'll
not be able to read into details yet in the next few days due to flooded
inbox.. sorry for that.  But I'll come back after I flush the rest.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2024-09-10 13:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-09 14:25 [PATCH RESEND RFC 00/10] migration: auto-converge refinements for huge VM Hyman Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 01/10] migration: Introduce structs for periodic CPU throttle Hyman Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 02/10] migration: Refine util functions to support " Hyman Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 03/10] qapi/migration: Introduce periodic CPU throttling parameters Hyman Huang
2024-09-09 21:30   ` Peter Xu
2024-09-10  5:47     ` Yong Huang
2024-09-10 13:56       ` Peter Xu [this message]
2024-09-09 14:25 ` [PATCH RESEND RFC 04/10] qapi/migration: Introduce the iteration-count Hyman Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 05/10] migration: Introduce util functions for periodic CPU throttle Hyman Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 06/10] migration: Support " Hyman Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 07/10] tests/migration-tests: Add test case for periodic throttle Hyman Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 08/10] migration: Introduce cpu-responsive-throttle parameter Hyman Huang
2024-09-10  6:00   ` Yong Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 09/10] migration: Support responsive CPU throttle Hyman Huang
2024-09-09 14:25 ` [PATCH RESEND RFC 10/10] tests/migration-tests: Add test case for " Hyman Huang

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=ZuBP90uSWiJWXTgQ@x1n \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=david@redhat.com \
    --cc=eblake@redhat.com \
    --cc=farosas@suse.de \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=yong.huang@smartx.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).