diff options
author | RajithaY <rajithax.yerrumsetty@intel.com> | 2017-04-25 03:31:15 -0700 |
---|---|---|
committer | Rajitha Yerrumchetty <rajithax.yerrumsetty@intel.com> | 2017-05-22 06:48:08 +0000 |
commit | bb756eebdac6fd24e8919e2c43f7d2c8c4091f59 (patch) | |
tree | ca11e03542edf2d8f631efeca5e1626d211107e3 /qemu/docs/throttle.txt | |
parent | a14b48d18a9ed03ec191cf16b162206998a895ce (diff) |
Adding qemu as a submodule of KVMFORNFV
This Patch includes the changes to add qemu as a submodule to
kvmfornfv repo and make use of the updated latest qemu for the
execution of all testcase
Change-Id: I1280af507a857675c7f81d30c95255635667bdd7
Signed-off-by:RajithaY<rajithax.yerrumsetty@intel.com>
Diffstat (limited to 'qemu/docs/throttle.txt')
-rw-r--r-- | qemu/docs/throttle.txt | 252 |
1 files changed, 0 insertions, 252 deletions
diff --git a/qemu/docs/throttle.txt b/qemu/docs/throttle.txt deleted file mode 100644 index 28204e46c..000000000 --- a/qemu/docs/throttle.txt +++ /dev/null @@ -1,252 +0,0 @@ -The QEMU throttling infrastructure -================================== -Copyright (C) 2016 Igalia, S.L. -Author: Alberto Garcia <berto@igalia.com> - -This work is licensed under the terms of the GNU GPL, version 2 or -later. See the COPYING file in the top-level directory. - -Introduction ------------- -QEMU includes a throttling module that can be used to set limits to -I/O operations. The code itself is generic and independent of the I/O -units, but it is currenly used to limit the number of bytes per second -and operations per second (IOPS) when performing disk I/O. - -This document explains how to use the throttling code in QEMU, and how -it works internally. The implementation is in throttle.c. - - -Using throttling to limit disk I/O ----------------------------------- -Two aspects of the disk I/O can be limited: the number of bytes per -second and the number of operations per second (IOPS). For each one of -them the user can set a global limit or separate limits for read and -write operations. This gives us a total of six different parameters. - -I/O limits can be set using the throttling.* parameters of -drive, or -using the QMP 'block_set_io_throttle' command. These are the names of -the parameters for both cases: - -|-----------------------+-----------------------| -| -drive | block_set_io_throttle | -|-----------------------+-----------------------| -| throttling.iops-total | iops | -| throttling.iops-read | iops_rd | -| throttling.iops-write | iops_wr | -| throttling.bps-total | bps | -| throttling.bps-read | bps_rd | -| throttling.bps-write | bps_wr | -|-----------------------+-----------------------| - -It is possible to set limits for both IOPS and bps and the same time, -and for each case we can decide whether to have separate read and -write limits or not, but note that if iops-total is set then neither -iops-read nor iops-write can be set. The same applies to bps-total and -bps-read/write. - -The default value of these parameters is 0, and it means 'unlimited'. - -In its most basic usage, the user can add a drive to QEMU with a limit -of 100 IOPS with the following -drive line: - - -drive file=hd0.qcow2,throttling.iops-total=100 - -We can do the same using QMP. In this case all these parameters are -mandatory, so we must set to 0 the ones that we don't want to limit: - - { "execute": "block_set_io_throttle", - "arguments": { - "device": "virtio0", - "iops": 100, - "iops_rd": 0, - "iops_wr": 0, - "bps": 0, - "bps_rd": 0, - "bps_wr": 0 - } - } - - -I/O bursts ----------- -In addition to the basic limits we have just seen, QEMU allows the -user to do bursts of I/O for a configurable amount of time. A burst is -an amount of I/O that can exceed the basic limit. Bursts are useful to -allow better performance when there are peaks of activity (the OS -boots, a service needs to be restarted) while keeping the average -limits lower the rest of the time. - -Two parameters control bursts: their length and the maximum amount of -I/O they allow. These two can be configured separately for each one of -the six basic parameters described in the previous section, but in -this section we'll use 'iops-total' as an example. - -The I/O limit during bursts is set using 'iops-total-max', and the -maximum length (in seconds) is set with 'iops-total-max-length'. So if -we want to configure a drive with a basic limit of 100 IOPS and allow -bursts of 2000 IOPS for 60 seconds, we would do it like this (the line -is split for clarity): - - -drive file=hd0.qcow2, - throttling.iops-total=100, - throttling.iops-total-max=2000, - throttling.iops-total-max-length=60 - -Or, with QMP: - - { "execute": "block_set_io_throttle", - "arguments": { - "device": "virtio0", - "iops": 100, - "iops_rd": 0, - "iops_wr": 0, - "bps": 0, - "bps_rd": 0, - "bps_wr": 0, - "iops_max": 2000, - "iops_max_length": 60, - } - } - -With this, the user can perform I/O on hd0.qcow2 at a rate of 2000 -IOPS for 1 minute before it's throttled down to 100 IOPS. - -The user will be able to do bursts again if there's a sufficiently -long period of time with unused I/O (see below for details). - -The default value for 'iops-total-max' is 0 and it means that bursts -are not allowed. 'iops-total-max-length' can only be set if -'iops-total-max' is set as well, and its default value is 1 second. - -Here's the complete list of parameters for configuring bursts: - -|----------------------------------+-----------------------| -| -drive | block_set_io_throttle | -|----------------------------------+-----------------------| -| throttling.iops-total-max | iops_max | -| throttling.iops-total-max-length | iops_max_length | -| throttling.iops-read-max | iops_rd_max | -| throttling.iops-read-max-length | iops_rd_max_length | -| throttling.iops-write-max | iops_wr_max | -| throttling.iops-write-max-length | iops_wr_max_length | -| throttling.bps-total-max | bps_max | -| throttling.bps-total-max-length | bps_max_length | -| throttling.bps-read-max | bps_rd_max | -| throttling.bps-read-max-length | bps_rd_max_length | -| throttling.bps-write-max | bps_wr_max | -| throttling.bps-write-max-length | bps_wr_max_length | -|----------------------------------+-----------------------| - - -Controlling the size of I/O operations --------------------------------------- -When applying IOPS limits all I/O operations are treated equally -regardless of their size. This means that the user can take advantage -of this in order to circumvent the limits and submit one huge I/O -request instead of several smaller ones. - -QEMU provides a setting called throttling.iops-size to prevent this -from happening. This setting specifies the size (in bytes) of an I/O -request for accounting purposes. Larger requests will be counted -proportionally to this size. - -For example, if iops-size is set to 4096 then an 8KB request will be -counted as two, and a 6KB request will be counted as one and a -half. This only applies to requests larger than iops-size: smaller -requests will be always counted as one, no matter their size. - -The default value of iops-size is 0 and it means that the size of the -requests is never taken into account when applying IOPS limits. - - -Applying I/O limits to groups of disks --------------------------------------- -In all the examples so far we have seen how to apply limits to the I/O -performed on individual drives, but QEMU allows grouping drives so -they all share the same limits. - -The way it works is that each drive with I/O limits is assigned to a -group named using the throttling.group parameter. If this parameter is -not specified, then the device name (i.e. 'virtio0', 'ide0-hd0') will -be used as the group name. - -Limits set using the throttling.* parameters discussed earlier in this -document apply to the combined I/O of all members of a group. - -Consider this example: - - -drive file=hd1.qcow2,throttling.iops-total=6000,throttling.group=foo - -drive file=hd2.qcow2,throttling.iops-total=6000,throttling.group=foo - -drive file=hd3.qcow2,throttling.iops-total=3000,throttling.group=bar - -drive file=hd4.qcow2,throttling.iops-total=6000,throttling.group=foo - -drive file=hd5.qcow2,throttling.iops-total=3000,throttling.group=bar - -drive file=hd6.qcow2,throttling.iops-total=5000 - -Here hd1, hd2 and hd4 are all members of a group named 'foo' with a -combined IOPS limit of 6000, and hd3 and hd5 are members of 'bar'. hd6 -is left alone (technically it is part of a 1-member group). - -Limits are applied in a round-robin fashion so if there are concurrent -I/O requests on several drives of the same group they will be -distributed evenly. - -When I/O limits are applied to an existing drive using the QMP command -'block_set_io_throttle', the following things need to be taken into -account: - - - I/O limits are shared within the same group, so new values will - affect all members and overwrite the previous settings. In other - words: if different limits are applied to members of the same - group, the last one wins. - - - If 'group' is unset it is assumed to be the current group of that - drive. If the drive is not in a group yet, it will be added to a - group named after the device name. - - - If 'group' is set then the drive will be moved to that group if - it was member of a different one. In this case the limits - specified in the parameters will be applied to the new group - only. - - - I/O limits can be disabled by setting all of them to 0. In this - case the device will be removed from its group and the rest of - its members will not be affected. The 'group' parameter is - ignored. - - -The Leaky Bucket algorithm --------------------------- -I/O limits in QEMU are implemented using the leaky bucket algorithm -(specifically the "Leaky bucket as a meter" variant). - -This algorithm uses the analogy of a bucket that leaks water -constantly. The water that gets into the bucket represents the I/O -that has been performed, and no more I/O is allowed once the bucket is -full. - -To see the way this corresponds to the throttling parameters in QEMU, -consider the following values: - - iops-total=100 - iops-total-max=2000 - iops-total-max-length=60 - - - Water leaks from the bucket at a rate of 100 IOPS. - - Water can be added to the bucket at a rate of 2000 IOPS. - - The size of the bucket is 2000 x 60 = 120000 - - If 'iops-total-max-length' is unset then the bucket size is 100. - -The bucket is initially empty, therefore water can be added until it's -full at a rate of 2000 IOPS (the burst rate). Once the bucket is full -we can only add as much water as it leaks, therefore the I/O rate is -reduced to 100 IOPS. If we add less water than it leaks then the -bucket will start to empty, allowing for bursts again. - -Note that since water is leaking from the bucket even during bursts, -it will take a bit more than 60 seconds at 2000 IOPS to fill it -up. After those 60 seconds the bucket will have leaked 60 x 100 = -6000, allowing for 3 more seconds of I/O at 2000 IOPS. - -Also, due to the way the algorithm works, longer burst can be done at -a lower I/O rate, e.g. 1000 IOPS during 120 seconds. |