)]}'
{
  "commit": "af4acfaf3ca2f1da6e48d67e50f27f5e22fa3308",
  "tree": "e563577a2a106b1c4b45507a6a8d729e4f650061",
  "parents": [
    "5650bff7fdf4f586d05dad9315d4786eba694149"
  ],
  "author": {
    "name": "Mizuma, Masayoshi",
    "email": "m.mizuma@jp.fujitsu.com",
    "time": "Mon Apr 07 15:37:54 2014 -0700"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@linuxfoundation.org",
    "time": "Tue May 06 07:51:45 2014 -0700"
  },
  "message": "mm: hugetlb: fix softlockup when a large number of hugepages are freed.\n\ncommit 55f67141a8927b2be3e51840da37b8a2320143ed upstream.\n\nWhen I decrease the value of nr_hugepage in procfs a lot, softlockup\nhappens.  It is because there is no chance of context switch during this\nprocess.\n\nOn the other hand, when I allocate a large number of hugepages, there is\nsome chance of context switch.  Hence softlockup doesn\u0027t happen during\nthis process.  So it\u0027s necessary to add the context switch in the\nfreeing process as same as allocating process to avoid softlockup.\n\nWhen I freed 12 TB hugapages with kernel-2.6.32-358.el6, the freeing\nprocess occupied a CPU over 150 seconds and following softlockup message\nappeared twice or more.\n\n$ echo 6000000 \u003e /proc/sys/vm/nr_hugepages\n$ cat /proc/sys/vm/nr_hugepages\n6000000\n$ grep ^Huge /proc/meminfo\nHugePages_Total:   6000000\nHugePages_Free:    6000000\nHugePages_Rsvd:        0\nHugePages_Surp:        0\nHugepagesize:       2048 kB\n$ echo 0 \u003e /proc/sys/vm/nr_hugepages\n\nBUG: soft lockup - CPU#16 stuck for 67s! [sh:12883] ...\nPid: 12883, comm: sh Not tainted 2.6.32-358.el6.x86_64 #1\nCall Trace:\n  free_pool_huge_page+0xb8/0xd0\n  set_max_huge_pages+0x128/0x190\n  hugetlb_sysctl_handler_common+0x113/0x140\n  hugetlb_sysctl_handler+0x1e/0x20\n  proc_sys_call_handler+0x97/0xd0\n  proc_sys_write+0x14/0x20\n  vfs_write+0xb8/0x1a0\n  sys_write+0x51/0x90\n  __audit_syscall_exit+0x265/0x290\n  system_call_fastpath+0x16/0x1b\n\nI have not confirmed this problem with upstream kernels because I am not\nable to prepare the machine equipped with 12TB memory now.  However I\nconfirmed that the amount of decreasing hugepages was directly\nproportional to the amount of required time.\n\nI measured required times on a smaller machine.  It showed 130-145\nhugepages decreased in a millisecond.\n\n  Amount of decreasing     Required time      Decreasing rate\n  hugepages                     (msec)         (pages/msec)\n  ------------------------------------------------------------\n  10,000 pages \u003d\u003d 20GB         70 -  74          135-142\n  30,000 pages \u003d\u003d 60GB        208 - 229          131-144\n\nIt means decrement of 6TB hugepages will trigger softlockup with the\ndefault threshold 20sec, in this decreasing rate.\n\nSigned-off-by: Masayoshi Mizuma \u003cm.mizuma@jp.fujitsu.com\u003e\nCc: Joonsoo Kim \u003ciamjoonsoo.kim@lge.com\u003e\nCc: Michal Hocko \u003cmhocko@suse.cz\u003e\nCc: Wanpeng Li \u003cliwanp@linux.vnet.ibm.com\u003e\nCc: Aneesh Kumar \u003caneesh.kumar@linux.vnet.ibm.com\u003e\nCc: KOSAKI Motohiro \u003ckosaki.motohiro@jp.fujitsu.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\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7111f2f5af68a7bb1e3ab3cb8768cb41dece167f",
      "old_mode": 33188,
      "old_path": "mm/hugetlb.c",
      "new_id": "c8eed94343e0277e19ff40d6817372c314f0bcce",
      "new_mode": 33188,
      "new_path": "mm/hugetlb.c"
    }
  ]
}