)]}'
{
  "commit": "fd57bb32eeed7fd4d2b8971ae8f6c39f4c5a70b4",
  "tree": "d5ad33a7ccff26c9d72635ee4e48b8b8ea27f53c",
  "parents": [
    "50ea0450cd886f7abb8f2c6dbb8c3a77d7c6edb3"
  ],
  "author": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Mon Aug 14 12:01:09 2017 -0400"
  },
  "committer": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Mon Aug 14 17:02:20 2017 -0400"
  },
  "message": "vmm: Prioritize task threads over guest threads\n\nOriginally, we had some task threads that would busy wait, so we had to\nalternate between tasks and guests.  Otherwise, the task threads would\nstarve the guests.\n\nHowever, with Gan\u0027s \"thread per timer tick per core\" change, multicore VMs\nrunning on an SCP VMMs ran into problems.  The guest cores would starve out\nthe task threads.  Specifically, every guest LAPIC timer tick we\u0027d create N\ntask threads.  We\u0027d run one of them, then the next *vcore* tick we\u0027d run a\nguest thread - which would spin in Linux in smp_call_function().  The N-1\nother alarms would wait.  By the time those threads got their chance to run\n(vcore tick), we\u0027d also have N more LAPIC timer threads created.  So we\u0027d\ngrow the number of threads by N-1 every tick (1 msec).\n\nAnyway, this turned out to be an easy fix: prioritize task threads, like I\noriginally wanted to.  The old task thread that was busy waiting was\nreplaced a while ago.\n\nSigned-off-by: Barret Rhoden \u003cbrho@cs.berkeley.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b44c44f6dc2ae6c68b3ebc53951afd1a981141fd",
      "old_mode": 33188,
      "old_path": "user/vmm/sched.c",
      "new_id": "dd937028188ee7f8edaf7ff0b706bd9b9a344ddb",
      "new_mode": 33188,
      "new_path": "user/vmm/sched.c"
    }
  ]
}