|
From: | Hyman Huang |
Subject: | Re: [PATCH v3 4/7] migration/dirtyrate: add per-vcpu option for calc-dirty-rate |
Date: | Tue, 8 Jun 2021 00:16:03 +0800 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 |
在 2021/6/7 23:46, Peter Xu 写道:
i'll change 'sample-pages' to '*sample-pages' in the first commit "migration/dirtyrate: make sample page count configurable" so that the following patch won't touch existing exported field.On Mon, Jun 07, 2021 at 09:12:36AM +0800, huangy81@chinatelecom.cn wrote:@@ -1751,7 +1770,9 @@ 'status': 'DirtyRateStatus', 'start-time': 'int64', 'calc-time': 'int64', - 'sample-pages': 'uint64'} } + '*sample-pages': 'uint64', + 'per-vcpu': 'bool', + '*vcpu-dirty-rate': [ 'DirtyRateVcpu' ] } }Ideally we shouldn't touch existing exported fields? I know it's not a problem since it's just introduced and together with the series.. The other alternative is to keep it as is but just ignore it in the result (or set it to zero for per-vcpu sampling)? No strong opinion.
indeed, the last version ignore this advice, i'll introduce the "per-vcpu" in the last patch, before it implemented.### @calc-dirty-rate: @@ -1760,6 +1781,10 @@ # # @calc-time: time in units of second for sample dirty pages # +# @per-vcpu: calculate vcpu dirty rate if true, the default value is +# false, note that the per-vcpu and sample-pages are mutually +# exclusive (since 6.1) +# # @sample-pages: page count per GB for sample dirty pages # the default value is 512 (since 6.1) # @@ -1769,7 +1794,7 @@ # {"command": "calc-dirty-rate", "data": {"calc-time": 1, 'sample-pages': 512} } # ## -{ 'command': 'calc-dirty-rate', 'data': {'calc-time': 'int64', '*sample-pages': 'int'} } +{ 'command': 'calc-dirty-rate', 'data': {'calc-time': 'int64', 'per-vcpu': 'bool', '*sample-pages': 'int'} }I still think exporting this new feature should happen as/in the last patch.
Also, wondering whether the name "per-vcpu" would let people think of "samping pages per-vcpu only", not showing that it's a completely new mechanism inside. How about make it a new parameter "*mode" (and I think even with per-vcpu it should be optional as "*per-vcpu") default to "page-sampling" and add a new "dirty-ring"?
i prefer the "*mode" parameter to show the different dirty rate method.
uh, actually this idea is what i'm working on to stat the memory heat(trying to reduce the transferred memory in migration), theoretically it can be used for dirty rate measurement also, maybe i could try it after this patchset work having done.Actually I'm also wondering whether dirty log could be anything useful here in the future as a 3rd mode (then the "*mode" idea should be more useful if so), basically for old kernels where dirty ring is not there, we can timely call memory_global_dirty_log_sync() and calculate dirty pages there just like what we do with dirty rings (without calling migration_bitmap_sync(), so we don't need to deliver dirty bits from kvmslots to ramblocks, just pick them up from kvm and do the accounting for pure dirty rate measurement). That's a wild idea though, so just raise it up. Would that be anything useful?
-- Best regard Hyman Huang(黄勇)
[Prev in Thread] | Current Thread | [Next in Thread] |