)]}'
{
  "commit": "20a77776c24800d1e40a73f520cfcb32239568a9",
  "tree": "8a28cc68cf10b87d35b7603b2d6f26215390cc0f",
  "parents": [
    "b84a35be0285229b0a8a5e2e04d79360c5b75562"
  ],
  "author": {
    "name": "Nick Piggin",
    "email": "nickpiggin@yahoo.com.au",
    "time": "Sun May 01 08:58:37 2005 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@ppc970.osdl.org",
    "time": "Sun May 01 08:58:37 2005 -0700"
  },
  "message": "[PATCH] mempool: simplify alloc\n\nMempool is pretty clever.  Looks too clever for its own good :) It\nshouldn\u0027t really know so much about page reclaim internals.\n\n- don\u0027t guess about what effective page reclaim might involve.\n\n- don\u0027t randomly flush out all dirty data if some unlikely thing\n  happens (alloc returns NULL). page reclaim can (sort of :P) handle\n  it.\n\nI think the main motivation is trying to avoid pool-\u003elock at all costs.\nHowever the first allocation is attempted with __GFP_WAIT cleared, so it\nwill be \u0027can_try_harder\u0027 if it hits the page allocator.  So if allocation\nstill fails, then we can probably afford to hit the pool-\u003elock - and what\u0027s\nthe alternative?  Try page reclaim and hit zone-\u003elru_lock?\n\nA nice upshot is that we don\u0027t need to do any fancy memory barriers or do\n(intentionally) racy access to pool-\u003e fields outside the lock.\n\nSigned-off-by: Nick Piggin \u003cnickpiggin@yahoo.com.au\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d691b5cb8022c640a1b4fc7538cccfce24970003",
      "old_mode": 33188,
      "old_path": "mm/mempool.c",
      "new_id": "e9a0a6337b21f66d72b765d79993cd6e74c40c64",
      "new_mode": 33188,
      "new_path": "mm/mempool.c"
    }
  ]
}