)]}'
{
  "commit": "7381131cbcf7e15d201a0ffd782a4698efe4e740",
  "tree": "83f00c40d0a3fcd41ff2e6681a5da70dd155628a",
  "parents": [
    "be3ffa276446e1b691a2bf84e7621e5a6fb49db9"
  ],
  "author": {
    "name": "Wu Fengguang",
    "email": "fengguang.wu@intel.com",
    "time": "Fri Aug 26 15:53:24 2011 -0600"
  },
  "committer": {
    "name": "Wu Fengguang",
    "email": "fengguang.wu@intel.com",
    "time": "Mon Oct 03 21:08:57 2011 +0800"
  },
  "message": "writeback: stabilize bdi-\u003edirty_ratelimit\n\nThere are some imperfections in balanced_dirty_ratelimit.\n\n1) large fluctuations\n\nThe dirty_rate used for computing balanced_dirty_ratelimit is merely\naveraged in the past 200ms (very small comparing to the 3s estimation\nperiod for write_bw), which makes rather dispersed distribution of\nbalanced_dirty_ratelimit.\n\nIt\u0027s pretty hard to average out the singular points by increasing the\nestimation period. Considering that the averaging technique will\nintroduce very undesirable time lags, I give it up totally. (btw, the 3s\nwrite_bw averaging time lag is much more acceptable because its impact\nis one-way and therefore won\u0027t lead to oscillations.)\n\nThe more practical way is filtering -- most singular\nbalanced_dirty_ratelimit points can be filtered out by remembering some\nprev_balanced_rate and prev_prev_balanced_rate. However the more\nreliable way is to guard balanced_dirty_ratelimit with task_ratelimit.\n\n2) due to truncates and fs redirties, the (write_bw \u003c\u003d\u003e dirty_rate)\nmatch could become unbalanced, which may lead to large systematical\nerrors in balanced_dirty_ratelimit. The truncates, due to its possibly\nbumpy nature, can hardly be compensated smoothly. So let\u0027s face it. When\nsome over-estimated balanced_dirty_ratelimit brings dirty_ratelimit\nhigh, dirty pages will go higher than the setpoint. task_ratelimit will\nin turn become lower than dirty_ratelimit.  So if we consider both\nbalanced_dirty_ratelimit and task_ratelimit and update dirty_ratelimit\nonly when they are on the same side of dirty_ratelimit, the systematical\nerrors in balanced_dirty_ratelimit won\u0027t be able to bring\ndirty_ratelimit far away.\n\nThe balanced_dirty_ratelimit estimation may also be inaccurate near\n@limit or @freerun, however is less an issue.\n\n3) since we ultimately want to\n\n- keep the fluctuations of task ratelimit as small as possible\n- keep the dirty pages around the setpoint as long time as possible\n\nthe update policy used for (2) also serves the above goals nicely:\nif for some reason the dirty pages are high (task_ratelimit \u003c dirty_ratelimit),\nand dirty_ratelimit is low (dirty_ratelimit \u003c balanced_dirty_ratelimit),\nthere is no point to bring up dirty_ratelimit in a hurry only to hurt\nboth the above two goals.\n\nSo, we make use of task_ratelimit to limit the update of dirty_ratelimit\nin two ways:\n\n1) avoid changing dirty rate when it\u0027s against the position control target\n   (the adjusted rate will slow down the progress of dirty pages going\n   back to setpoint).\n\n2) limit the step size. task_ratelimit is changing values step by step,\n   leaving a consistent trace comparing to the randomly jumping\n   balanced_dirty_ratelimit. task_ratelimit also has the nice smaller\n   errors in stable state and typically larger errors when there are big\n   errors in rate.  So it\u0027s a pretty good limiting factor for the step\n   size of dirty_ratelimit.\n\nNote that bdi-\u003edirty_ratelimit is always tracking balanced_dirty_ratelimit.\ntask_ratelimit is merely used as a limiting factor.\n\nSigned-off-by: Wu Fengguang \u003cfengguang.wu@intel.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "dff0ff78e8780ce40b1787e449656215916e530f",
      "old_mode": 33188,
      "old_path": "include/linux/backing-dev.h",
      "new_id": "c3b92010d894aa1a7ec061a32817ff256c9873f5",
      "new_mode": 33188,
      "new_path": "include/linux/backing-dev.h"
    },
    {
      "type": "modify",
      "old_id": "ba20f94cde938644f9c68aaf4285427cd3de4776",
      "old_mode": 33188,
      "old_path": "mm/backing-dev.c",
      "new_id": "5dcaa3c756d179f40abdb03fac487e23399e04d7",
      "new_mode": 33188,
      "new_path": "mm/backing-dev.c"
    },
    {
      "type": "modify",
      "old_id": "1721b6523c04f4602b6cb8ae1e15a7f5f710e654",
      "old_mode": 33188,
      "old_path": "mm/page-writeback.c",
      "new_id": "d4a6e91bd9e54ada7e2289573880084a6a691562",
      "new_mode": 33188,
      "new_path": "mm/page-writeback.c"
    }
  ]
}