)]}'
{
  "commit": "a79311c14eae4bb946a97af25f3e1b17d625985d",
  "tree": "f12391481dfd7a1c3ffcff75bd04d3a88957d16c",
  "parents": [
    "ebdd4aea8d736e3b5ce27ab0a26860c9fded341b"
  ],
  "author": {
    "name": "Rik van Riel",
    "email": "riel@redhat.com",
    "time": "Tue Jan 06 14:40:01 2009 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Tue Jan 06 15:59:06 2009 -0800"
  },
  "message": "vmscan: bail out of direct reclaim after swap_cluster_max pages\n\nWhen the VM is under pressure, it can happen that several direct reclaim\nprocesses are in the pageout code simultaneously.  It also happens that\nthe reclaiming processes run into mostly referenced, mapped and dirty\npages in the first round.\n\nThis results in multiple direct reclaim processes having a lower\npageout priority, which corresponds to a higher target of pages to\nscan.\n\nThis in turn can result in each direct reclaim process freeing\nmany pages.  Together, they can end up freeing way too many pages.\n\nThis kicks useful data out of memory (in some cases more than half\nof all memory is swapped out).  It also impacts performance by\nkeeping tasks stuck in the pageout code for too long.\n\nA 30% improvement in hackbench has been observed with this patch.\n\nThe fix is relatively simple: in shrink_zone() we can check how many\npages we have already freed, direct reclaim tasks break out of the\nscanning loop if they have already freed enough pages and have reached\na lower priority level.\n\nWe do not break out of shrink_zone() when priority \u003d\u003d DEF_PRIORITY,\nto ensure that equal pressure is applied to every zone in the common\ncase.\n\nHowever, in order to do this we do need to know how many pages we already\nfreed, so move nr_reclaimed into scan_control.\n\nakpm: a historical interlude...\n\nWe tried this in 2004:\n\n:commit e468e46a9bea3297011d5918663ce6d19094cf87\n:Author: akpm \u003cakpm\u003e\n:Date:   Thu Jun 24 15:53:52 2004 +0000\n:\n:[PATCH] vmscan.c: dont reclaim too many pages\n:\n:    The shrink_zone() logic can, under some circumstances, cause far too many\n:    pages to be reclaimed.  Say, we\u0027re scanning at high priority and suddenly hit\n:    a large number of reclaimable pages on the LRU.\n:    Change things so we bale out when SWAP_CLUSTER_MAX pages have been reclaimed.\n\nAnd we reverted it in 2006:\n\n:commit 210fe530305ee50cd889fe9250168228b2994f32\n:Author: Andrew Morton \u003cakpm@osdl.org\u003e\n:Date:   Fri Jan 6 00:11:14 2006 -0800\n:\n:    [PATCH] vmscan: balancing fix\n:\n:    Revert a patch which went into 2.6.8-rc1.  The changelog for that patch was:\n:\n:      The shrink_zone() logic can, under some circumstances, cause far too many\n:      pages to be reclaimed.  Say, we\u0027re scanning at high priority and suddenly\n:      hit a large number of reclaimable pages on the LRU.\n:\n:      Change things so we bale out when SWAP_CLUSTER_MAX pages have been\n:      reclaimed.\n:\n:    Problem is, this change caused significant imbalance in inter-zone scan\n:    balancing by truncating scans of larger zones.\n:\n:    Suppose, for example, ZONE_HIGHMEM is 10x the size of ZONE_NORMAL.  The zone\n:    balancing algorithm would require that if we\u0027re scanning 100 pages of\n:    ZONE_HIGHMEM, we should scan 10 pages of ZONE_NORMAL.  But this logic will\n:    cause the scanning of ZONE_HIGHMEM to bale out after only 32 pages are\n:    reclaimed.  Thus effectively causing smaller zones to be scanned relatively\n:    harder than large ones.\n:\n:    Now I need to remember what the workload was which caused me to write this\n:    patch originally, then fix it up in a different way...\n\nAnd we haven\u0027t demonstrated that whatever problem caused that reversion is\nnot being reintroduced by this change in 2008.\n\nSigned-off-by: Rik van Riel \u003criel@redhat.com\u003e\nCc: KOSAKI Motohiro \u003ckosaki.motohiro@jp.fujitsu.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1ef5a2eeb29811aa358edf21c219a2877a1224ee",
      "old_mode": 33188,
      "old_path": "mm/vmscan.c",
      "new_id": "5faa7739487f9e9da92f1e8c3a59f00cac1deb32",
      "new_mode": 33188,
      "new_path": "mm/vmscan.c"
    }
  ]
}