|
From: | Hyman Huang |
Subject: | Re: [PATCH v11 3/4] softmmu/dirtylimit: implement virtual CPU throttle |
Date: | Thu, 20 Jan 2022 18:39:01 +0800 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 |
在 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(黄勇)
[Prev in Thread] | Current Thread | [Next in Thread] |