)]}'
{
  "commit": "8382d914ebf72092aa15cdc2a5dcedb2daa0209d",
  "tree": "34eb3000a1ebbd3a5a6efc49a2ec649bccaecc97",
  "parents": [
    "4e35f483850ba46b838adfd312b3052416e15204"
  ],
  "author": {
    "name": "Davidlohr Bueso",
    "email": "davidlohr@hp.com",
    "time": "Thu Apr 03 14:47:31 2014 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Apr 03 16:21:00 2014 -0700"
  },
  "message": "mm, hugetlb: improve page-fault scalability\n\nThe kernel can currently only handle a single hugetlb page fault at a\ntime.  This is due to a single mutex that serializes the entire path.\nThis lock protects from spurious OOM errors under conditions of low\navailability of free hugepages.  This problem is specific to hugepages,\nbecause it is normal to want to use every single hugepage in the system\n- with normal pages we simply assume there will always be a few spare\npages which can be used temporarily until the race is resolved.\n\nAddress this problem by using a table of mutexes, allowing a better\nchance of parallelization, where each hugepage is individually\nserialized.  The hash key is selected depending on the mapping type.\nFor shared ones it consists of the address space and file offset being\nfaulted; while for private ones the mm and virtual address are used.\nThe size of the table is selected based on a compromise of collisions\nand memory footprint of a series of database workloads.\n\nLarge database workloads that make heavy use of hugepages can be\nparticularly exposed to this issue, causing start-up times to be\npainfully slow.  This patch reduces the startup time of a 10 Gb Oracle\nDB (with ~5000 faults) from 37.5 secs to 25.7 secs.  Larger workloads\nwill naturally benefit even more.\n\nNOTE:\nThe only downside to this patch, detected by Joonsoo Kim, is that a\nsmall race is possible in private mappings: A child process (with its\nown mm, after cow) can instantiate a page that is already being handled\nby the parent in a cow fault.  When low on pages, can trigger spurious\nOOMs.  I have not been able to think of a efficient way of handling\nthis...  but do we really care about such a tiny window? We already\nmaintain another theoretical race with normal pages.  If not, one\npossible way to is to maintain the single hash for private mappings --\nany workloads that *really* suffer from this scaling problem should\nalready use shared mappings.\n\n[akpm@linux-foundation.org: remove stray + characters, go BUG if hugetlb_init() kmalloc fails]\nSigned-off-by: Davidlohr Bueso \u003cdavidlohr@hp.com\u003e\nCc: Aneesh Kumar K.V \u003caneesh.kumar@linux.vnet.ibm.com\u003e\nCc: David Gibson \u003cdavid@gibson.dropbear.id.au\u003e\nCc: Joonsoo Kim \u003ciamjoonsoo.kim@lge.com\u003e\nCc: Naoya Horiguchi \u003cn-horiguchi@ah.jp.nec.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": "1c7baff65f9d0b8bde099fb24c2cf9e82702a993",
      "old_mode": 33188,
      "old_path": "mm/hugetlb.c",
      "new_id": "38d9bed88dc8910dfb91cc7875386598e6db6f5f",
      "new_mode": 33188,
      "new_path": "mm/hugetlb.c"
    }
  ]
}