Re: [PATCH v22 0/8] support dirty restraint on vCPU
Whose review is still needed? Or is this ready? ---There is no review in the the process. Two month ago, David has tried to queue this patch and reported a test failure, i fix this by add a test case for dirtylimit.So i think it's ready for the next migration queue. How do you think of this? David -- Yong On 4/27/2022 14:21，Markus Armbruster wrote： Peter Xu writes: Hi, Yong, On Mon, Apr 25, 2022 at 12:52:45AM +0800, Hyman wrote: Ping. Hi, David and Peter, how do you think this patchset? Is it suitable for queueing ? or is there still something need to be done ? It keeps looking good to me in general, let's see whether the maintainers have any comments. Thanks,Whose review is still needed? Or is this ready?
Re: [PATCH v22 0/8] support dirty restraint on vCPU
Peter Xu writes: > Hi, Yong, > > On Mon, Apr 25, 2022 at 12:52:45AM +0800, Hyman wrote: >> Ping. >> Hi, David and Peter, how do you think this patchset? >> Is it suitable for queueing ? or is there still something need to be done ? > > It keeps looking good to me in general, let's see whether the maintainers > have any comments. Thanks, Whose review is still needed? Or is this ready?
Re: [PATCH v22 0/8] support dirty restraint on vCPU
Hi, Yong, On Mon, Apr 25, 2022 at 12:52:45AM +0800, Hyman wrote: > Ping. > Hi, David and Peter, how do you think this patchset? > Is it suitable for queueing ? or is there still something need to be done ? It keeps looking good to me in general, let's see whether the maintainers have any comments. Thanks, -- Peter Xu
Re: [PATCH v22 0/8] support dirty restraint on vCPU
Ping. Hi, David and Peter, how do you think this patchset? Is it suitable for queueing ? or is there still something need to be done ? Yong 在 2022/4/1 1:49, huang...@chinatelecom.cn 写道: From: Hyman Huang(黄勇) This is v22 of dirtylimit series. The following is the history of the patchset, since v22 kind of different from the original version, i made abstracts of changelog: RFC and v1: https://lore.kernel.org/qemu-devel/cover.1637214721.git.huang...@chinatelecom.cn/ v2: https://lore.kernel.org/qemu-devel/cover.1637256224.git.huang...@chinatelecom.cn/ v1->v2 changelog: - rename some function and variables. refactor the original algo of dirtylimit. Thanks for the comments given by Juan Quintela. v3: https://lore.kernel.org/qemu-devel/cover.1637403404.git.huang...@chinatelecom.cn/ v4: https://lore.kernel.org/qemu-devel/cover.1637653303.git.huang...@chinatelecom.cn/ v5: https://lore.kernel.org/qemu-devel/cover.1637759139.git.huang...@chinatelecom.cn/ v6: https://lore.kernel.org/qemu-devel/cover.1637856472.git.huang...@chinatelecom.cn/ v7: https://lore.kernel.org/qemu-devel/cover.1638202004.git.huang...@chinatelecom.cn/ v2->v7 changelog: - refactor the docs, annotation and fix bugs of the original algo of dirtylimit. Thanks for the review given by Markus Armbruster. v8: https://lore.kernel.org/qemu-devel/cover.1638463260.git.huang...@chinatelecom.cn/ v9: https://lore.kernel.org/qemu-devel/cover.1638495274.git.huang...@chinatelecom.cn/ v10: https://lore.kernel.org/qemu-devel/cover.1639479557.git.huang...@chinatelecom.cn/ v7->v10 changelog: - introduce a simpler but more efficient algo of dirtylimit inspired by Peter Xu. - keep polishing the annotation suggested by Markus Armbruster. v11: https://lore.kernel.org/qemu-devel/cover.1641315745.git.huang...@chinatelecom.cn/ v12: https://lore.kernel.org/qemu-devel/cover.1642774952.git.huang...@chinatelecom.cn/ v13: https://lore.kernel.org/qemu-devel/cover.1644506963.git.huang...@chinatelecom.cn/ v10->v13 changelog: - handle the hotplug/unplug scenario. - refactor the new algo, split the commit and make the code more clean. v14: https://lore.kernel.org/qemu-devel/cover.1644509582.git.huang...@chinatelecom.cn/ v13->v14 changelog: - sent by accident. v15: https://lore.kernel.org/qemu-devel/cover.1644976045.git.huang...@chinatelecom.cn/ v16: https://lore.kernel.org/qemu-devel/cover.1645067452.git.huang...@chinatelecom.cn/ v17: https://lore.kernel.org/qemu-devel/cover.1646243252.git.huang...@chinatelecom.cn/ v14->v17 changelog: - do some code clean and fix test bug reported by Dr. David Alan Gilbert. v18: https://lore.kernel.org/qemu-devel/cover.1646247968.git.huang...@chinatelecom.cn/ v19: https://lore.kernel.org/qemu-devel/cover.1647390160.git.huang...@chinatelecom.cn/ v20: https://lore.kernel.org/qemu-devel/cover.1647396907.git.huang...@chinatelecom.cn/ v21: https://lore.kernel.org/qemu-devel/cover.1647435820.git.huang...@chinatelecom.cn/ v17->v21 changelog: - add qtest, fix bug and do code clean. v21->v22 changelog: - move the vcpu dirty limit test into migration-test and do some modification suggested by Peter. Please review. Yong. Abstract This patchset introduce a mechanism to impose dirty restraint on vCPU, aiming to keep the vCPU running in a certain dirtyrate given by user. dirty restraint on vCPU maybe an alternative method to implement convergence logic for live migration, which could improve guest memory performance during migration compared with traditional method in theory. For the current live migration implementation, the convergence logic throttles all vCPUs of the VM, which has some side effects. -'read processes' on vCPU will be unnecessarily penalized - throttle increase percentage step by step, which seems struggling to find the optimal throttle percentage when dirtyrate is high. - hard to predict the remaining time of migration if the throttling percentage reachs 99% to a certain extent, the dirty restraint machnism can fix these effects by throttling at vCPU granularity during migration. the implementation is rather straightforward, we calculate vCPU dirtyrate via the Dirty Ring mechanism periodically as the commit 0e21bf246 "implement dirty-ring dirtyrate calculation" does, for vCPU that be specified to impose dirty restraint, we throttle it periodically as the auto-converge does, once after throttling, we compare the quota dirtyrate with current dirtyrate, if current dirtyrate is not under the quota, increase the throttling percentage until current dirtyrate is under the quota. this patchset is the basis of implmenting a new auto-converge method for live migration, we introduce two qmp commands for impose/cancel the dirty restraint on specified vCPU, so it also can be an independent api to supply the upper app such as libvirt, which can use it to implement the convergence logic during live migration, supplemented with the qmp 'calc-dirty-rate' command or whatever. we post this
[PATCH v22 0/8] support dirty restraint on vCPU
From: Hyman Huang(黄勇) This is v22 of dirtylimit series. The following is the history of the patchset, since v22 kind of different from the original version, i made abstracts of changelog: RFC and v1: https://lore.kernel.org/qemu-devel/cover.1637214721.git.huang...@chinatelecom.cn/ v2: https://lore.kernel.org/qemu-devel/cover.1637256224.git.huang...@chinatelecom.cn/ v1->v2 changelog: - rename some function and variables. refactor the original algo of dirtylimit. Thanks for the comments given by Juan Quintela. v3: https://lore.kernel.org/qemu-devel/cover.1637403404.git.huang...@chinatelecom.cn/ v4: https://lore.kernel.org/qemu-devel/cover.1637653303.git.huang...@chinatelecom.cn/ v5: https://lore.kernel.org/qemu-devel/cover.1637759139.git.huang...@chinatelecom.cn/ v6: https://lore.kernel.org/qemu-devel/cover.1637856472.git.huang...@chinatelecom.cn/ v7: https://lore.kernel.org/qemu-devel/cover.1638202004.git.huang...@chinatelecom.cn/ v2->v7 changelog: - refactor the docs, annotation and fix bugs of the original algo of dirtylimit. Thanks for the review given by Markus Armbruster. v8: https://lore.kernel.org/qemu-devel/cover.1638463260.git.huang...@chinatelecom.cn/ v9: https://lore.kernel.org/qemu-devel/cover.1638495274.git.huang...@chinatelecom.cn/ v10: https://lore.kernel.org/qemu-devel/cover.1639479557.git.huang...@chinatelecom.cn/ v7->v10 changelog: - introduce a simpler but more efficient algo of dirtylimit inspired by Peter Xu. - keep polishing the annotation suggested by Markus Armbruster. v11: https://lore.kernel.org/qemu-devel/cover.1641315745.git.huang...@chinatelecom.cn/ v12: https://lore.kernel.org/qemu-devel/cover.1642774952.git.huang...@chinatelecom.cn/ v13: https://lore.kernel.org/qemu-devel/cover.1644506963.git.huang...@chinatelecom.cn/ v10->v13 changelog: - handle the hotplug/unplug scenario. - refactor the new algo, split the commit and make the code more clean. v14: https://lore.kernel.org/qemu-devel/cover.1644509582.git.huang...@chinatelecom.cn/ v13->v14 changelog: - sent by accident. v15: https://lore.kernel.org/qemu-devel/cover.1644976045.git.huang...@chinatelecom.cn/ v16: https://lore.kernel.org/qemu-devel/cover.1645067452.git.huang...@chinatelecom.cn/ v17: https://lore.kernel.org/qemu-devel/cover.1646243252.git.huang...@chinatelecom.cn/ v14->v17 changelog: - do some code clean and fix test bug reported by Dr. David Alan Gilbert. v18: https://lore.kernel.org/qemu-devel/cover.1646247968.git.huang...@chinatelecom.cn/ v19: https://lore.kernel.org/qemu-devel/cover.1647390160.git.huang...@chinatelecom.cn/ v20: https://lore.kernel.org/qemu-devel/cover.1647396907.git.huang...@chinatelecom.cn/ v21: https://lore.kernel.org/qemu-devel/cover.1647435820.git.huang...@chinatelecom.cn/ v17->v21 changelog: - add qtest, fix bug and do code clean. v21->v22 changelog: - move the vcpu dirty limit test into migration-test and do some modification suggested by Peter. Please review. Yong. Abstract This patchset introduce a mechanism to impose dirty restraint on vCPU, aiming to keep the vCPU running in a certain dirtyrate given by user. dirty restraint on vCPU maybe an alternative method to implement convergence logic for live migration, which could improve guest memory performance during migration compared with traditional method in theory. For the current live migration implementation, the convergence logic throttles all vCPUs of the VM, which has some side effects. -'read processes' on vCPU will be unnecessarily penalized - throttle increase percentage step by step, which seems struggling to find the optimal throttle percentage when dirtyrate is high. - hard to predict the remaining time of migration if the throttling percentage reachs 99% to a certain extent, the dirty restraint machnism can fix these effects by throttling at vCPU granularity during migration. the implementation is rather straightforward, we calculate vCPU dirtyrate via the Dirty Ring mechanism periodically as the commit 0e21bf246 "implement dirty-ring dirtyrate calculation" does, for vCPU that be specified to impose dirty restraint, we throttle it periodically as the auto-converge does, once after throttling, we compare the quota dirtyrate with current dirtyrate, if current dirtyrate is not under the quota, increase the throttling percentage until current dirtyrate is under the quota. this patchset is the basis of implmenting a new auto-converge method for live migration, we introduce two qmp commands for impose/cancel the dirty restraint on specified vCPU, so it also can be an independent api to supply the upper app such as libvirt, which can use it to implement the convergence logic during live migration, supplemented with the qmp 'calc-dirty-rate' command or whatever. we post this patchset for RFC and any corrections and suggetions about the implementation, api, throttleing algorithm or whatever are very appreciated! Please review, thanks ! Best Regards ! Hyman Huang
