|
From: | Hyman |
Subject: | Re: [PATCH v8 0/6] support dirtyrate at the granualrity of vcpu |
Date: | Sat, 19 Jun 2021 00:36:30 +0800 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
在 2021/6/19 0:00, Peter Xu 写道:
from my point, absolutely yes, since we have introduced the dirty ring, the most valuable sicenario i think is to improve migration or at least provide another auto-converge implementation to management apps, it seems that there is no reason not trying this.On Fri, Jun 18, 2021 at 11:32:01PM +0800, huangy81@chinatelecom.cn wrote:From: Hyman Huang(黄勇) <huangy81@chinatelecom.cn> v8I have one last comment in patch 2, the rest looks good to me, thanks. I think the next step can be that we add another command to configure dirty rate limit for each of the vcpu. It can be the 3rd bit in the global_dirty_tracking and it should require dirty ring too to be there, but I haven't thought deeper.. Then after that, we may teach migration code some algorithm to auto-setup these per-vcpu throttling, it'll grow into some kind of per-vcpu auto-converge. Do you think above would be something worth trying out? And.. Dave/Paolo/Juan?
Ok, i'll rebase and post another version later, may be commit "KVM: Fix dirty ring mmap incorrect size due to renaming accident" should be merged before this, so that dirty rate calculation can work rightly.Btw, this series cannot apply cleanly to master here. Maybe you need to pull and rebase?
[Prev in Thread] | Current Thread | [Next in Thread] |