)]}'
{
  "commit": "c4cc6d07b2f465fbf5efd99bbe772a49c515f3f2",
  "tree": "0aec353fce4ee6cd16e3051ecfdf55e8022aaa5a",
  "parents": [
    "75897d60a54ccee94253312107f941a83b5077cb"
  ],
  "author": {
    "name": "Hugh Dickins",
    "email": "hugh@veritas.com",
    "time": "Mon Feb 04 22:28:40 2008 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@woody.linux-foundation.org",
    "time": "Tue Feb 05 09:44:14 2008 -0800"
  },
  "message": "swapin_readahead: excise NUMA bogosity\n\nFor three years swapin_readahead has been cluttered with fanciful CONFIG_NUMA\ncode, advancing addr, and stepping on to the next vma at the boundary, to line\nup the mempolicy for each page allocation.\n\nIt _might_ be a good idea to allocate swap more according to vma layout; but\nthe fact is, that\u0027s not how we do it at all, 2.6 even less than 2.4: swap is\nallocated as needed for pages as they sink to the bottom of the inactive LRUs.\n Sometimes that may match vma layout, but not so often that it\u0027s worth going\nto these misleading vma-\u003evm_next lengths: rip all that out.\n\nOriginally I intended to retain the incrementation of addr, but correct its\ninitial value: valid_swaphandles generally supplies an offset below the target\naddr (this is readaround rather than readahead), but addr has not been\nadjusted accordingly, so in the interleave case it has usually been allocating\nthe target page from the \"wrong\" node (though that may not matter very much).\n\nBut look at the equivalent shmem_swapin code: either by oversight or by\ndesign, though it has all the apparatus for choosing a new mempolicy per page,\nit uses the same idx throughout, choosing the same mempolicy and interleave\nnode for each page of the cluster.\n\nWhich is actually a much better strategy: each node has its own LRUs and its\nown kswapd, so if you\u0027re betting on any particular relationship between swap\nand node, the best bet is that nearby swap entries belong to pages from the\nsame node - even when the mempolicy of the target page is to interleave.  And\nexamining a map of nodes corresponding to swap entries on a numa\u003dfake system\nbears this out.  (We could later tweak swap allocation to make it even more\nlikely, but this patch is merely about removing cruft.)\n\nSo, neither adjust nor increment addr in swapin_readahead, and then\nshmem_swapin can use it too; the pseudo-vma to pass policy need only be set up\nonce per cluster, and so few fields of pvma are used, let\u0027s skip the memset -\nfrom shmem_alloc_page also.\n\nSigned-off-by: Hugh Dickins \u003chugh@veritas.com\u003e\nAcked-by: Rik van Riel \u003criel@redhat.com\u003e\nCc: Andi Kleen \u003cak@suse.de\u003e\nCc: Christoph Lameter \u003cclameter@sgi.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": "1b8ca160f1d04fadee04fedd82955b1c40585927",
      "old_mode": 33188,
      "old_path": "mm/memory.c",
      "new_id": "1d803c2d01848dedb1e9eb57d640eaa81bd8a4cc",
      "new_mode": 33188,
      "new_path": "mm/memory.c"
    },
    {
      "type": "modify",
      "old_id": "51b3d6ccddab75ba33b7fded5ffaf75700770ccd",
      "old_mode": 33188,
      "old_path": "mm/shmem.c",
      "new_id": "88c6685f16b715b00378fc26cf7d7b9a43dd79bd",
      "new_mode": 33188,
      "new_path": "mm/shmem.c"
    }
  ]
}