)]}'
{
  "commit": "aedcd72f6c283dffefbb8b808ae67bdd2c6eb11a",
  "tree": "62b4cee6a4f3ae622068d48a00e177ad06ac04f4",
  "parents": [
    "2edd2c740b2918eb0a9a1fe1b69678b903769ec2"
  ],
  "author": {
    "name": "Jens Axboe",
    "email": "axboe@fb.com",
    "time": "Wed Sep 17 08:27:03 2014 -0600"
  },
  "committer": {
    "name": "Jens Axboe",
    "email": "axboe@fb.com",
    "time": "Mon Sep 22 12:00:08 2014 -0600"
  },
  "message": "blk-mq: limit memory consumption if a crash dump is active\n\nIt\u0027s not uncommon for crash dump kernels to be limited to 128MB or\nsomething low in that area. This is normally not a problem for\ndevices as we don\u0027t use that much memory, but for some shared SCSI\nsetups with huge queue depths, it can potentially fill most of\nmemory with tons of request allocations. blk-mq does scale back\nwhen it fails to allocate memory, but it scales back just enough\nso that blk-mq succeeds. This could still leave the system with\nnot enough memory to make any real progress.\n\nCheck if we are in a kdump environment and limit the hardware\nqueues and tag depth.\n\nSigned-off-by: Jens Axboe \u003caxboe@fb.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3b277b4eaa95ac8d08d185bc1ab5a9cc99c684c9",
      "old_mode": 33188,
      "old_path": "block/blk-mq.c",
      "new_id": "c5345a95182035901820553d6606c49dc3a388f1",
      "new_mode": 33188,
      "new_path": "block/blk-mq.c"
    }
  ]
}