)]}'
{
  "commit": "3401a61e16a5b852d4e353c8850c857105a67a9c",
  "tree": "5e05731a790c48512c7fe41c5fc83b0fee6081e3",
  "parents": [
    "4d2e7d0d77e4e1e8a21cc990c607985fdba20e66"
  ],
  "author": {
    "name": "Christian Borntraeger",
    "email": "borntraeger@de.ibm.com",
    "time": "Thu May 08 15:20:38 2008 +0200"
  },
  "committer": {
    "name": "Rusty Russell",
    "email": "rusty@rustcorp.com.au",
    "time": "Fri May 23 13:09:34 2008 +1000"
  },
  "message": "stop_machine: make stop_machine_run more virtualization friendly\n\nOn kvm I have seen some rare hangs in stop_machine when I used more guest\ncpus than hosts cpus. e.g. 32 guest cpus on 1 host cpu triggered the\nhang quite often. I could also reproduce the problem on a 4 way z/VM host with\na 64 way guest.\n\nIt turned out that the guest was consuming all available cpus mostly for\nspinning on scheduler locks like rq-\u003elock. This is expected as the threads are\ncalling yield all the time.\nThe problem is now, that the host scheduling decisings together with the guest\nscheduling decisions and spinlocks not being fair managed to create an\ninteresting scenario similar to a live lock. (Sometimes the hang resolved\nitself after some minutes)\n\nChanging stop_machine to yield the cpu to the hypervisor when yielding inside\nthe guest fixed the problem for me. While I am not completely happy with this\npatch, I think it causes no harm and it really improves the situation for me.\n\nI used cpu_relax for yielding to the hypervisor, does that work on all\narchitectures?\n\np.s.: If you want to reproduce the problem, cpu hotplug and kprobes use\nstop_machine_run and both triggered the problem after some retries.\n\nSigned-off-by: Christian Borntraeger \u003cborntraeger@de.ibm.com\u003e\nCC: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Rusty Russell \u003crusty@rustcorp.com.au\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0101aeef7ed79fbd62aba8d1043976a110cf1f6e",
      "old_mode": 33188,
      "old_path": "kernel/stop_machine.c",
      "new_id": "b7350bbfb076293dd6d13d7ba060b3aba1f673a9",
      "new_mode": 33188,
      "new_path": "kernel/stop_machine.c"
    }
  ]
}