)]}'
{
  "commit": "56fd56b868f19385c50af8941a4c78df433b2d32",
  "tree": "5ea8362e6e141e2d1124d4640811c76489567bc5",
  "parents": [
    "5c0e3066474b57c56ff0d88ca31d95bd14232fee"
  ],
  "author": {
    "name": "Mel Gorman",
    "email": "mel@csn.ul.ie",
    "time": "Tue Oct 16 01:25:58 2007 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@woody.linux-foundation.org",
    "time": "Tue Oct 16 09:43:00 2007 -0700"
  },
  "message": "Bias the location of pages freed for min_free_kbytes in the same MAX_ORDER_NR_PAGES blocks\n\nThe standard buddy allocator always favours the smallest block of pages.\nThe effect of this is that the pages free to satisfy min_free_kbytes tends\nto be preserved since boot time at the same location of memory ffor a very\nlong time and as a contiguous block.  When an administrator sets the\nreserve at 16384 at boot time, it tends to be the same MAX_ORDER blocks\nthat remain free.  This allows the occasional high atomic allocation to\nsucceed up until the point the blocks are split.  In practice, it is\ndifficult to split these blocks but when they do split, the benefit of\nhaving min_free_kbytes for contiguous blocks disappears.  Additionally,\nincreasing min_free_kbytes once the system has been running for some time\nhas no guarantee of creating contiguous blocks.\n\nOn the other hand, CONFIG_PAGE_GROUP_BY_MOBILITY favours splitting large\nblocks when there are no free pages of the appropriate type available.  A\nside-effect of this is that all blocks in memory tends to be used up and\nthe contiguous free blocks from boot time are not preserved like in the\nvanilla allocator.  This can cause a problem if a new caller is unwilling\nto reclaim or does not reclaim for long enough.\n\nA failure scenario was found for a wireless network device allocating\norder-1 atomic allocations but the allocations were not intense or frequent\nenough for a whole block of pages to be preserved for MIGRATE_HIGHALLOC.\nThis was reproduced on a desktop by booting with mem\u003d256mb, forcing the\ndriver to allocate at order-1, running a bittorrent client (downloading a\ndebian ISO) and building a kernel with -j2.\n\nThis patch addresses the problem on the desktop machine booted with\nmem\u003d256mb.  It works by setting aside a reserve of MAX_ORDER_NR_PAGES\nblocks, the number of which depends on the value of min_free_kbytes.  These\nblocks are only fallen back to when there is no other free pages.  Then the\nsmallest possible page is used just like the normal buddy allocator instead\nof the largest possible page to preserve contiguous pages The pages in free\nlists in the reserve blocks are never taken for another migrate type.  The\nresults is that even if min_free_kbytes is set to a low value, contiguous\nblocks will be preserved in the MIGRATE_RESERVE blocks.\n\nThis works better than the vanilla allocator because if min_free_kbytes is\nincreased, a new reserve block will be chosen based on the location of\nreclaimable pages and the block will free up as contiguous pages.  In the\nvanilla allocator, no effort is made to target a block of pages to free as\ncontiguous pages and min_free_kbytes pages are scattered randomly.\n\nThis effect has been observed on the test machine.  min_free_kbytes was set\ninitially low but it was kept as a contiguous free block within\nMIGRATE_RESERVE.  min_free_kbytes was then set to a higher value and over a\nperiod of time, the free blocks were within the reserve and coalescing.\nHow long it takes to free up depends on how quickly LRU is rotating.\nAmusingly, this means that more activity will free the blocks faster.\n\nThis mechanism potentially replaces MIGRATE_HIGHALLOC as it may be more\neffective than grouping contiguous free pages together.  It all depends on\nwhether the number of active atomic high allocations exceeds\nmin_free_kbytes or not.  If the number of active allocations exceeds\nmin_free_kbytes, it\u0027s worth it but maybe in that situation, min_free_kbytes\nshould be set higher.  Once there are no more reports of allocation\nfailures, a patch will be submitted that backs out MIGRATE_HIGHALLOC and\nsee if the reports stay missing.\n\nCredit to Mariusz Kozlowski for discovering the problem, describing the\nfailure scenario and testing patches and scenarios.\n\n[akpm@linux-foundation.org: cleanups]\nSigned-off-by: Mel Gorman \u003cmel@csn.ul.ie\u003e\nAcked-by: Andy Whitcroft \u003capw@shadowen.org\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": "9a5d5590bd393e0856d5a046d838246935b43383",
      "old_mode": 33188,
      "old_path": "include/linux/mmzone.h",
      "new_id": "afdec8117458a8728cef2d3163e4753290be8219",
      "new_mode": 33188,
      "new_path": "include/linux/mmzone.h"
    },
    {
      "type": "modify",
      "old_id": "5456da6b4ade76b7b8887b2bb009e2fe9c770177",
      "old_mode": 33188,
      "old_path": "include/linux/pageblock-flags.h",
      "new_id": "fa3b1001894b6c436a4d89c3a55847aab4ee7d15",
      "new_mode": 33188,
      "new_path": "include/linux/pageblock-flags.h"
    },
    {
      "type": "modify",
      "old_id": "b864584c92b467d384b21ab93685052328542cab",
      "old_mode": 33188,
      "old_path": "mm/page_alloc.c",
      "new_id": "f7873a47fa8e3e73dd696c2c7c4b4d4cccd8e787",
      "new_mode": 33188,
      "new_path": "mm/page_alloc.c"
    }
  ]
}