All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyman Huang <huangy81@chinatelecom.cn>
To: Peter Xu <peterx@redhat.com>
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
	"David Hildenbrand" <david@redhat.com>,
	"Juan Quintela" <quintela@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Markus ArmBruster" <armbru@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v11 3/4] softmmu/dirtylimit: implement virtual CPU throttle
Date: Thu, 20 Jan 2022 18:39:01 +0800	[thread overview]
Message-ID: <c6086788-da45-d023-edaa-5fca9a602c5a@chinatelecom.cn> (raw)
In-Reply-To: <Yekqn90HOtFMWupM@xz-m1.local>



在 2022/1/20 17:25, Peter Xu 写道:

> 
> ... I think what you explained makes sense to me.
> 
> Note that there's also the reaper thread running in the background that can
> reap all the cores too.
> 
> It only runs once per second so it shouldn't bring a lot of differences, but
> I'm also wondering whether we should also turn that temporarily off too when
> dirtylimit is enabled - we can simply let it keep sleeping if dirtylimit is in
> service.
Does this work ok when dirtylimit and migration happens concurrently?
Migration may fetch the aged dirty bitmap info from slot if we turn 
reaper thread off. As you metioned above, reaper thread only runs once 
per second. Is it more suitable for not touching the reaper thread logic?
> 
> Dropping BQL may not be safe, as it serializes the reaping with other possible
> kvm memslot updates.  I don't know whether it's a must in the future to use BQL
> for reaping the rings, but so far I'd say we can still stick with it.
> 
> Note that even if you don't take BQL you'll still need the slots_lock and so
> far that's also global, so I don't see how it can help on vcpu concurrency
> anyway even if we dropped one of them.
> 
> If to do this, could you not introduce kvm_dirty_ring_reset_one() but just let
> it take one more CPUState* parameter?  Most of the codes you added should be
> similar to kvm_dirty_ring_reap_locked(), and I wanted to keep the trace point
> there (trace_kvm_dirty_ring_reap, though that needs another parameter too).
> 
> And that patch can be done on top of this patch, so it can be reviewed easier
> outside of dirtylimit details.
> 
> Thanks,
> 

-- 
Best regard

Hyman Huang(黄勇)


  parent reply	other threads:[~2022-01-20 13:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 17:14 [PATCH v11 0/4] support dirty restraint on vCPU huangy81
     [not found] ` <cover.1641316375.git.huangy81@chinatelecom.cn>
2022-01-04 17:14   ` [PATCH v11 1/4] migration/dirtyrate: refactor dirty page rate calculation huangy81
2022-01-17  2:19     ` Peter Xu
2022-01-22  3:22       ` Hyman Huang
2022-01-24  3:08         ` Peter Xu
2022-01-24  9:36           ` Hyman Huang
2022-01-04 17:14   ` [PATCH v11 2/4] softmmu/dirtylimit: implement vCPU dirtyrate calculation periodically huangy81
2022-01-17  2:31     ` Peter Xu
2022-01-04 17:14   ` [PATCH v11 3/4] softmmu/dirtylimit: implement virtual CPU throttle huangy81
2022-01-17  7:32     ` Peter Xu
2022-01-17 14:00       ` Hyman Huang
2022-01-18  1:00         ` Peter Xu
2022-01-18  2:08           ` Hyman Huang
2022-01-20  8:26       ` Hyman Huang
2022-01-20  9:25         ` Peter Xu
2022-01-20 10:03           ` Hyman Huang
2022-01-20 10:58             ` Peter Xu
2022-01-20 10:39           ` Hyman Huang [this message]
2022-01-20 10:56             ` Peter Xu
2022-01-20 11:03               ` Hyman Huang
2022-01-20 11:13                 ` Peter Xu
2022-01-21  8:07       ` Hyman Huang
2022-01-21  9:19         ` Peter Xu
2022-01-22  3:54       ` Hyman Huang
2022-01-24  3:10         ` Peter Xu
2022-01-24  4:20       ` Hyman Huang
2022-01-17  9:01     ` Peter Xu
2022-01-19 12:16     ` Markus Armbruster
2022-01-20 11:22       ` Hyman Huang
2022-01-04 17:14   ` [PATCH v11 4/4] softmmu/dirtylimit: implement dirty page rate limit huangy81
2022-01-17  7:35     ` Peter Xu
2022-01-19 12:16     ` Markus Armbruster
2022-01-17  8:54 ` [PATCH v11 0/4] support dirty restraint on vCPU 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=c6086788-da45-d023-edaa-5fca9a602c5a@chinatelecom.cn \
    --to=huangy81@chinatelecom.cn \
    --cc=armbru@redhat.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=richard.henderson@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.