)]}'
{
  "commit": "8edb08caf68184fb170f4f69c7445929e199eaea",
  "tree": "c0d8f24971c90e5627207f0f0cb7c06f9bdb5dc4",
  "parents": [
    "fa07e787733416c42938a310a8e717295934e33c"
  ],
  "author": {
    "name": "Lee Schermerhorn",
    "email": "lee.schermerhorn@hp.com",
    "time": "Sat Oct 18 20:26:49 2008 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Mon Oct 20 08:52:31 2008 -0700"
  },
  "message": "mlock: downgrade mmap sem while populating mlocked regions\n\nWe need to hold the mmap_sem for write to initiatate mlock()/munlock()\nbecause we may need to merge/split vmas.  However, this can lead to very\nlong lock hold times attempting to fault in a large memory region to mlock\nit into memory.  This can hold off other faults against the mm\n[multithreaded tasks] and other scans of the mm, such as via /proc.  To\nalleviate this, downgrade the mmap_sem to read mode during the population\nof the region for locking.  This is especially the case if we need to\nreclaim memory to lock down the region.  We [probably?] don\u0027t need to do\nthis for unlocking as all of the pages should be resident--they\u0027re already\nmlocked.\n\nNow, the caller\u0027s of the mlock functions [mlock_fixup() and\nmlock_vma_pages_range()] expect the mmap_sem to be returned in write mode.\n Changing all callers appears to be way too much effort at this point.\nSo, restore write mode before returning.  Note that this opens a window\nwhere the mmap list could change in a multithreaded process.  So, at least\nfor mlock_fixup(), where we could be called in a loop over multiple vmas,\nwe check that a vma still exists at the start address and that vma still\ncovers the page range [start,end).  If not, we return an error, -EAGAIN,\nand let the caller deal with it.\n\nReturn -EAGAIN from mlock_vma_pages_range() function and mlock_fixup() if\nthe vma at \u0027start\u0027 disappears or changes so that the page range\n[start,end) is no longer contained in the vma.  Again, let the caller deal\nwith it.  Looks like only sys_remap_file_pages() [via mmap_region()]\nshould actually care.\n\nWith this patch, I no longer see processes like ps(1) blocked for seconds\nor minutes at a time waiting for a large [multiple gigabyte] region to be\nlocked down.  However, I occassionally see delays while unlocking or\nunmapping a large mlocked region.  Should we also downgrade the mmap_sem\nfor the unlock path?\n\nSigned-off-by: Lee Schermerhorn \u003clee.schermerhorn@hp.com\u003e\nSigned-off-by: Rik van Riel \u003criel@redhat.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": "8746fe3f973040e4447f880d853d3b8cb49419ec",
      "old_mode": 33188,
      "old_path": "mm/mlock.c",
      "new_id": "c83896a725042d45694777305107fd33ba9c9c28",
      "new_mode": 33188,
      "new_path": "mm/mlock.c"
    }
  ]
}