Files
ubports_kernel_google_msm/include/linux
Wu Fengguang bb0822954a squeeze max-pause area and drop pass-good area
Revert the pass-good area introduced in ffd1f609ab ("writeback:
introduce max-pause and pass-good dirty limits") and make the max-pause
area smaller and safe.

This fixes ~30% performance regression in the ext3 data=writeback
fio_mmap_randwrite_64k/fio_mmap_randrw_64k test cases, where there are
12 JBOD disks, on each disk runs 8 concurrent tasks doing reads+writes.

Using deadline scheduler also has a regression, but not that big as CFQ,
so this suggests we have some write starvation.

The test logs show that

- the disks are sometimes under utilized

- global dirty pages sometimes rush high to the pass-good area for
  several hundred seconds, while in the mean time some bdi dirty pages
  drop to very low value (bdi_dirty << bdi_thresh).  Then suddenly the
  global dirty pages dropped under global dirty threshold and bdi_dirty
  rush very high (for example, 2 times higher than bdi_thresh). During
  which time balance_dirty_pages() is not called at all.

So the problems are

1) The random writes progress so slow that they break the assumption of
   the max-pause logic that "8 pages per 200ms is typically more than
   enough to curb heavy dirtiers".

2) The max-pause logic ignored task_bdi_thresh and thus opens the possibility
   for some bdi's to over dirty pages, leading to (bdi_dirty >> bdi_thresh)
   and then (bdi_thresh >> bdi_dirty) for others.

3) The higher max-pause/pass-good thresholds somehow leads to the bad
   swing of dirty pages.

The fix is to allow the task to slightly dirty over task_bdi_thresh, but
no way to exceed bdi_dirty and/or global dirty_thresh.

Tests show that it fixed the JBOD regression completely (both behavior
and performance), while still being able to cut down large pause times
in balance_dirty_pages() for single-disk cases.

Reported-by: Li Shaohua <shaohua.li@intel.com>
Tested-by: Li Shaohua <shaohua.li@intel.com>
Acked-by: Jan Kara <jack@suse.cz>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
2011-08-19 22:42:07 +08:00
..
2011-07-26 16:49:47 -07:00
2011-07-22 08:25:37 -07:00
2011-07-26 16:49:47 -07:00
2011-07-20 20:47:43 -04:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-08-03 11:30:42 -04:00
2011-07-23 20:44:25 +02:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-08-03 19:06:37 -04:00
2011-07-26 16:49:47 -07:00
2011-07-06 14:44:42 -07:00
2011-07-25 20:57:16 -07:00
2011-07-05 23:42:17 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-05-29 13:03:09 +01:00
2011-07-26 16:49:47 -07:00
2011-06-25 17:29:52 +02:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-08-06 22:53:23 -07:00
2011-07-01 15:34:45 -07:00
2011-06-28 10:48:34 +02:00
2011-07-01 10:37:15 +02:00
2011-07-06 01:56:38 -07:00
2011-07-21 13:47:54 -07:00
2011-07-26 16:49:47 -07:00
2011-06-14 11:30:22 +02:00
2011-05-26 17:12:37 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-08-08 12:11:02 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-05 15:26:58 -04:00
2011-07-31 12:18:15 -04:00
2011-07-31 12:18:16 -04:00
2011-07-28 16:19:22 -06:00
2011-08-09 11:27:16 -06:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-05-26 17:12:37 -07:00
2011-07-22 16:14:29 -07:00
2011-07-26 16:49:47 -07:00
2011-07-23 07:56:59 +01:00
2011-07-26 16:49:47 -07:00
2011-06-07 10:02:35 +02:00
2011-07-26 16:49:47 -07:00
2011-07-30 08:44:19 -10:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00
2011-07-25 20:57:11 -07:00
2011-07-26 16:49:47 -07:00
2011-08-03 14:25:22 -10:00
2011-07-26 16:49:47 -07:00
2011-06-15 20:03:59 -07:00
2011-06-27 20:30:08 +02:00
2011-06-07 09:05:42 -07:00
2011-05-30 11:14:16 +09:30
2011-07-26 16:49:47 -07:00
2011-07-26 16:49:47 -07:00