)]}'
{
  "commit": "b70a2a21dc9d4ad455931b53131a0cb4fc01fafe",
  "tree": "95ad6c804009a5867ac991cc1edf414e163b40b4",
  "parents": [
    "3fbe724424fb104aaca9973389b4a9df428c3e2a"
  ],
  "author": {
    "name": "Johannes Weiner",
    "email": "hannes@cmpxchg.org",
    "time": "Thu Oct 09 15:28:56 2014 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Oct 09 22:25:59 2014 -0400"
  },
  "message": "mm: memcontrol: fix transparent huge page allocations under pressure\n\nIn a memcg with even just moderate cache pressure, success rates for\ntransparent huge page allocations drop to zero, wasting a lot of effort\nthat the allocator puts into assembling these pages.\n\nThe reason for this is that the memcg reclaim code was never designed for\nhigher-order charges.  It reclaims in small batches until there is room\nfor at least one page.  Huge page charges only succeed when these batches\nadd up over a series of huge faults, which is unlikely under any\nsignificant load involving order-0 allocations in the group.\n\nRemove that loop on the memcg side in favor of passing the actual reclaim\ngoal to direct reclaim, which is already set up and optimized to meet\nhigher-order goals efficiently.\n\nThis brings memcg\u0027s THP policy in line with the system policy: if the\nallocator painstakingly assembles a hugepage, memcg will at least make an\nhonest effort to charge it.  As a result, transparent hugepage allocation\nrates amid cache activity are drastically improved:\n\n                                      vanilla                 patched\npgalloc                 4717530.80 (  +0.00%)   4451376.40 (  -5.64%)\npgfault                  491370.60 (  +0.00%)    225477.40 ( -54.11%)\npgmajfault                    2.00 (  +0.00%)         1.80 (  -6.67%)\nthp_fault_alloc               0.00 (  +0.00%)       531.60 (+100.00%)\nthp_fault_fallback          749.00 (  +0.00%)       217.40 ( -70.88%)\n\n[ Note: this may in turn increase memory consumption from internal\n  fragmentation, which is an inherent risk of transparent hugepages.\n  Some setups may have to adjust the memcg limits accordingly to\n  accomodate this - or, if the machine is already packed to capacity,\n  disable the transparent huge page feature. ]\n\nSigned-off-by: Johannes Weiner \u003channes@cmpxchg.org\u003e\nReviewed-by: Vladimir Davydov \u003cvdavydov@parallels.com\u003e\nCc: Michal Hocko \u003cmhocko@suse.cz\u003e\nCc: Dave Hansen \u003cdave@sr71.net\u003e\nCc: Greg Thelen \u003cgthelen@google.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": "ea4f926e6b9b849588cec2ccde50ec5a80a48e65",
      "old_mode": 33188,
      "old_path": "include/linux/swap.h",
      "new_id": "37a585beef5cf86e27fe54bc9a444ce7874ac1d3",
      "new_mode": 33188,
      "new_path": "include/linux/swap.h"
    },
    {
      "type": "modify",
      "old_id": "9cda99dfac4f202a9bc69e4923245ee698ff842a",
      "old_mode": 33188,
      "old_path": "mm/memcontrol.c",
      "new_id": "c86cc442ada47c277bcf68f2d77a96c0272c629c",
      "new_mode": 33188,
      "new_path": "mm/memcontrol.c"
    },
    {
      "type": "modify",
      "old_id": "06123f20a3269fde64db1d94bb121197db59fdec",
      "old_mode": 33188,
      "old_path": "mm/vmscan.c",
      "new_id": "dcb47074ae03cdbe7ff4d823e116776b6dbc8673",
      "new_mode": 33188,
      "new_path": "mm/vmscan.c"
    }
  ]
}