[PATCH] reduce the default dirty memory thresholds

Writeback parameter tuning.  Somewhat experimental, but heading in the
right direction, I hope.

- Allowing 40% of physical memory to be dirtied on massive ia32 boxes
  is unreasonable.  It pins too many buffer_heads and contribues to
  page reclaim latency.

  The patch changes the initial value of
  /proc/sys/vm/dirty_background_ratio, dirty_async_ratio and (the
  presently non-functional) dirty_sync_ratio so that they are reduced
  when the highmem:lowmem ratio exceeds 4:1.

  These ratios are scaled so that as the highmem:lowmem ratio goes
  beyond 4:1, the maximum amount of allowed dirty memory ceases to
  increase.  It is clamped at the amount of memory which a 4:1 machine
  is allowed to use.

- Aggressive reduction in the dirty memory threshold at which
  background writeback cuts in.  2.4 uses 30% of ZONE_NORMAL.  2.5 uses
  40% of total memory.  This patch changes it to 10% of total memory
  (if total memory <= 4G.  Even less otherwise - see above).

This means that:

- Much more writeback is performed by pdflush.

- When the application is generating dirty data at a moderate
  rate, background writeback cuts in much earlier, so memory is
  cleaned more promptly.

- Reduces the risk of user applications getting stalled by writeback.

- Will damage dbench numbers.  It turns out that the damage is
  fairly small, and dbench isn't a worthwhile workload for
  optimisation.

- Moderate reduction in the dirty level at which the write(2) caller
  is forced to perform writeback (throttling).  Was 40% of total
  memory.  Is now 30% of total memory (if total memory <= 4G, less
  otherwise).

This is to reduce page reclaim latency, and generally because
allowing processes to flood the machine with dirty data is a bad
thing in mixed workloads.

0 files changed, 0 insertions, 0 deletions