qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Chao Fan <fanc.fnst@cn.fujitsu.com>
To: qemu-devel@nongnu.org
Cc: quintela@redhat.com, amit.shah@redhat.com,
	izumi.taku@jp.fujitsu.com, caoj.fnst@cn.fujitsu.com,
	douly.fnst@cn.fujitsu.com
Subject: [Qemu-devel] An issue for migration determining the cpu throttle value according to workload
Date: Tue, 6 Dec 2016 16:52:11 +0800	[thread overview]
Message-ID: <20161206085211.GC13801@localhost.localdomain> (raw)

Hi all,

Here is an issue in auto-converge feature of migration.

When migrating a guest which consumes too much CPU & memory, dirty
pages amount will increase significantly, so does the migration
time, migration can not even complete, at worst.

I did some simple tests on this feature. Set the two parameters
the same as 10,20,30,40,50,60,70,80,99 and run the same task in the
same guest. The result roughly is, with the increment of the
two parameters, the total_time and the dirty_sync_count will decrease.
Result shows larger the value of the two parameters is, faster the
migration is, but much more slowly the guest runs.

So I think there should be a appropriate throttle value according to
the workload of guest. But users do not know how to determine the
appropriate value.

So I want to do a job that qemu can set the throttle value according
to the workload of guest. I think qemu could calculate the instant
dirty pages rate, and then determine a appropriate throttle value.
The instant dirty pages rate means in a short fixed time, how
many dirty pages born. But I have two questions:
1. Where to add this feature. I have two options:
   a. Now qemu detects the rest migration time and decides whether
      to execute the CPU throttle. It can be changed to that qemu
      executes the CPU throttle when instant dirty pages rate increases
      to a certain threshold and sets the throttle value according to
      the instant dirty pages rate. 
   b. Using the current way as it is, when the rest migration time
      is too long and begin to execute the CPU throttle, assign
      appropriate throttle value according to the workload. Codes
      will be changed fewer in this method.
2. How to determine the CPU throttle value according to the dirty pages.
   My preliminary idea is, the CPU throttle should be related to
   the instant dirty pages rate and the total memory.
   But I am not sure how to do the map from instant dirty pages rate
   and total memory to CPU throttle value is best.

Any comments will be welcome, and I want to know whether more people
think this feature is needed.
If anyone has good ideas, please tell me.

Thanks,
Chao Fan

             reply	other threads:[~2016-12-06  8:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-06  8:52 Chao Fan [this message]
2016-12-12  2:04 ` [Qemu-devel] An issue for migration determining the cpu throttle value according to workload Chao Fan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161206085211.GC13801@localhost.localdomain \
    --to=fanc.fnst@cn.fujitsu.com \
    --cc=amit.shah@redhat.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=douly.fnst@cn.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).