)]}'
{
  "commit": "e31f3698cd3499e676f6b0ea12e3528f569c4fa3",
  "tree": "0133cc0e11384c7293bdf0812ee04996a02c8826",
  "parents": [
    "51980ac9e72fb5f22c81b7798d65b691125d70ee"
  ],
  "author": {
    "name": "Wu Fengguang",
    "email": "fengguang.wu@intel.com",
    "time": "Mon Aug 09 17:20:01 2010 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Mon Aug 09 20:45:03 2010 -0700"
  },
  "message": "vmscan: raise the bar to PAGEOUT_IO_SYNC stalls\n\nFix \"system goes unresponsive under memory pressure and lots of\ndirty/writeback pages\" bug.\n\n\thttp://lkml.org/lkml/2010/4/4/86\n\nIn the above thread, Andreas Mohr described that\n\n\tInvoking any command locked up for minutes (note that I\u0027m\n\ttalking about attempted additional I/O to the _other_,\n\t_unaffected_ main system HDD - such as loading some shell\n\tbinaries -, NOT the external SSD18M!!).\n\nThis happens when the two conditions are both meet:\n- under memory pressure\n- writing heavily to a slow device\n\nOOM also happens in Andreas\u0027 system.  The OOM trace shows that 3 processes\nare stuck in wait_on_page_writeback() in the direct reclaim path.  One in\ndo_fork() and the other two in unix_stream_sendmsg().  They are blocked on\nthis condition:\n\n\t(sc-\u003eorder \u0026\u0026 priority \u003c DEF_PRIORITY - 2)\n\nwhich was introduced in commit 78dc583d (vmscan: low order lumpy reclaim\nalso should use PAGEOUT_IO_SYNC) one year ago.  That condition may be too\npermissive.  In Andreas\u0027 case, 512MB/1024 \u003d 512KB.  If the direct reclaim\nfor the order-1 fork() allocation runs into a range of 512KB\nhard-to-reclaim LRU pages, it will be stalled.\n\nIt\u0027s a severe problem in three ways.\n\nFirstly, it can easily happen in daily desktop usage.  vmscan priority can\neasily go below (DEF_PRIORITY - 2) on _local_ memory pressure.  Even if\nthe system has 50% globally reclaimable pages, it still has good\nopportunity to have 0.1% sized hard-to-reclaim ranges.  For example, a\nsimple dd can easily create a big range (up to 20%) of dirty pages in the\nLRU lists.  And order-1 to order-3 allocations are more than common with\nSLUB.  Try \"grep -v \u00271 :\u0027 /proc/slabinfo\" to get the list of high order\nslab caches.  For example, the order-1 radix_tree_node slab cache may\nstall applications at swap-in time; the order-3 inode cache on most\nfilesystems may stall applications when trying to read some file; the\norder-2 proc_inode_cache may stall applications when trying to open a\n/proc file.\n\nSecondly, once triggered, it will stall unrelated processes (not doing IO\nat all) in the system.  This \"one slow USB device stalls the whole system\"\navalanching effect is very bad.\n\nThirdly, once stalled, the stall time could be intolerable long for the\nusers.  When there are 20MB queued writeback pages and USB 1.1 is writing\nthem in 1MB/s, wait_on_page_writeback() will stuck for up to 20 seconds.\nNot to mention it may be called multiple times.\n\nSo raise the bar to only enable PAGEOUT_IO_SYNC when priority goes below\nDEF_PRIORITY/3, or 6.25% LRU size.  As the default dirty throttle ratio is\n20%, it will hardly be triggered by pure dirty pages.  We\u0027d better treat\nPAGEOUT_IO_SYNC as some last resort workaround -- its stall time is so\nuncomfortably long (easily goes beyond 1s).\n\nThe bar is only raised for (order \u003c PAGE_ALLOC_COSTLY_ORDER) allocations,\nwhich are easy to satisfy in 1TB memory boxes.  So, although 6.25% of\nmemory could be an awful lot of pages to scan on a system with 1TB of\nmemory, it won\u0027t really have to busy scan that much.\n\nAndreas tested an older version of this patch and reported that it mostly\nfixed his problem.  Mel Gorman helped improve it and KOSAKI Motohiro will\nfix it further in the next patch.\n\nReported-by: Andreas Mohr \u003candi@lisas.de\u003e\nReviewed-by: Minchan Kim \u003cminchan.kim@gmail.com\u003e\nReviewed-by: KOSAKI Motohiro \u003ckosaki.motohiro@jp.fujitsu.com\u003e\nSigned-off-by: Mel Gorman \u003cmel@csn.ul.ie\u003e\nSigned-off-by: Wu Fengguang \u003cfengguang.wu@intel.com\u003e\nCc: Rik van Riel \u003criel@redhat.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": "154b37a3373110944b583666f57bc99679438839",
      "old_mode": 33188,
      "old_path": "mm/vmscan.c",
      "new_id": "ec5ddccbf82e9dbef3e23b7a6faa72283360eee4",
      "new_mode": 33188,
      "new_path": "mm/vmscan.c"
    }
  ]
}