)]}'
{
  "commit": "f14a39ccb922ee123741ae2cf70a10eef9a650fc",
  "tree": "308b6a882e86b9733952f20632564668e9689fd8",
  "parents": [
    "c834cba90521576224c30b15ebb4d6aeab7b42c4"
  ],
  "author": {
    "name": "Sascha Silbe",
    "email": "silbe@linux.vnet.ibm.com",
    "time": "Tue Jun 28 17:28:41 2016 +0200"
  },
  "committer": {
    "name": "Max Reitz",
    "email": "mreitz@redhat.com",
    "time": "Wed Jul 13 13:41:38 2016 +0200"
  },
  "message": "Improve block job rate limiting for small bandwidth values\n\nratelimit_calculate_delay() previously reset the accounting every time\nslice, no matter how much data had been processed before. This had (at\nleast) two consequences:\n\n1. The minimum speed is rather large, e.g. 5 MiB/s for commit and stream.\n\n   Not sure if there are real-world use cases where this would be a\n   problem. Mirroring and backup over a slow link (e.g. DSL) would\n   come to mind, though.\n\n2. Tests for block job operations (e.g. cancel) were rather racy\n\n   All block jobs currently use a time slice of 100ms. That\u0027s a\n   reasonable value to get smooth output during regular\n   operation. However this also meant that the state of block jobs\n   changed every 100ms, no matter how low the configured limit was. On\n   busy hosts, qemu often transferred additional chunks until the test\n   case had a chance to cancel the job.\n\nFix the block job rate limit code to delay for more than one time\nslice to address the above issues. To make it easier to handle\noversized chunks we switch the semantics from returning a delay\n_before_ the current request to a delay _after_ the current\nrequest. If necessary, this delay consists of multiple time slice\nunits.\n\nSince the mirror job sends multiple chunks in one go even if the rate\nlimit was exceeded in between, we need to keep track of the start of\nthe current time slice so we can correctly re-compute the delay for\nthe updated amount of data.\n\nThe minimum bandwidth now is 1 data unit per time slice. The block\njobs are currently passing the amount of data transferred in sectors\nand using 100ms time slices, so this translates to 5120\nbytes/second. With chunk sizes usually being O(512KiB), tests have\nplenty of time (O(100s)) to operate on block jobs. The chance of a\nrace condition now is fairly remote, except possibly on insanely\nloaded systems.\n\nSigned-off-by: Sascha Silbe \u003csilbe@linux.vnet.ibm.com\u003e\nMessage-id: 1467127721-9564-2-git-send-email-silbe@linux.vnet.ibm.com\nReviewed-by: Max Reitz \u003cmreitz@redhat.com\u003e\nSigned-off-by: Max Reitz \u003cmreitz@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5d11eb6103b5bb8f92d52ba567c3181c4b8f0c16",
      "old_mode": 33188,
      "old_path": "block/commit.c",
      "new_id": "553e18da52ef6a9b61a96aef60361f7ff963b161",
      "new_mode": 33188,
      "new_path": "block/commit.c"
    },
    {
      "type": "modify",
      "old_id": "71e5ad43773b8626b5bc5bdeeca842f97536251c",
      "old_mode": 33188,
      "old_path": "block/mirror.c",
      "new_id": "b1e633ecada26fd8561fc2f4457b909136a5d328",
      "new_mode": 33188,
      "new_path": "block/mirror.c"
    },
    {
      "type": "modify",
      "old_id": "2e7c6547d26377249a96804f08ecc541c87db2de",
      "old_mode": 33188,
      "old_path": "block/stream.c",
      "new_id": "31874817c2195aa8b1b49e75fb258e4df2674a02",
      "new_mode": 33188,
      "new_path": "block/stream.c"
    },
    {
      "type": "modify",
      "old_id": "1e3cb13b282000a355c92c2c97c1e6424d608b68",
      "old_mode": 33188,
      "old_path": "include/qemu/ratelimit.h",
      "new_id": "8da1232574883a6f4c2eeaf3afa761eaa281bd9c",
      "new_mode": 33188,
      "new_path": "include/qemu/ratelimit.h"
    }
  ]
}