| Message ID | 20180604095520.8563-3-xiaoguangrong@tencent.com |
|---|---|
| State | New |
| Headers | show |
| Series | migration: improve multithreads for compression and decompression | expand |
* guangrong.xiao@gmail.com (guangrong.xiao@gmail.com) wrote: > From: Xiao Guangrong <xiaoguangrong@tencent.com> > > The compressed page is not normal page Is this the right reason? I think we always increment some counter for a page - so what gets incremented for a compressed page? Is the real answer that we do: ram_save_target_page control_save_page compress_page_with_multi_thread and control_save_page already increments the counter? Dave > Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com> > --- > migration/ram.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/migration/ram.c b/migration/ram.c > index 0caf32ab0a..dbf24d8c87 100644 > --- a/migration/ram.c > +++ b/migration/ram.c > @@ -1432,7 +1432,6 @@ static int compress_page_with_multi_thread(RAMState *rs, RAMBlock *block, > qemu_cond_signal(&comp_param[idx].cond); > qemu_mutex_unlock(&comp_param[idx].mutex); > pages = 1; > - ram_counters.normal++; > ram_counters.transferred += bytes_xmit; > break; > } > -- > 2.14.4 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On 06/13/2018 11:51 PM, Dr. David Alan Gilbert wrote: > * guangrong.xiao@gmail.com (guangrong.xiao@gmail.com) wrote: >> From: Xiao Guangrong <xiaoguangrong@tencent.com> >> >> The compressed page is not normal page > > Is this the right reason? I think the 'normal' page shouldn't include the compressed page and XBZRLE-ed page (the current code does not treat xbzrle pages are normal as well). > I think we always increment some counter for a page - so > what gets incremented for a compressed page? In the later patch, we will introduce the statistics of compression which contains "pages": @pages: amount of pages compressed and transferred to the target VM > Is the real answer that we do: > > ram_save_target_page > control_save_page > compress_page_with_multi_thread > > and control_save_page already increments the counter? No :), control_save_page increments the counter only if it posted data out, under that case, the compression path is not invoked. Thanks!
diff --git a/migration/ram.c b/migration/ram.c index 0caf32ab0a..dbf24d8c87 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -1432,7 +1432,6 @@ static int compress_page_with_multi_thread(RAMState *rs, RAMBlock *block, qemu_cond_signal(&comp_param[idx].cond); qemu_mutex_unlock(&comp_param[idx].mutex); pages = 1; - ram_counters.normal++; ram_counters.transferred += bytes_xmit; break; }