)]}'
{
  "commit": "babe106ae71809d837a94471103af0cd34b40e9c",
  "tree": "6de154e30238d756a4e34743034ca1bbbd812aad",
  "parents": [
    "828f5ad57f415f00ea30c090ec834ed4eaaad8dd"
  ],
  "author": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Wed Jan 30 12:03:13 2019 -0500"
  },
  "committer": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Wed Jan 30 12:03:13 2019 -0500"
  },
  "message": "Pin ktasks to core 0\n\nKthreads can migrate due to the hardcoded policy of \"run kthreads on\nwhichever core woke them up.\"  This is technically a source of\ninterference for any MCP - consider a process that does as SYS_block /\nkthread_usleep on core 6, then yields.  The alarm goes off on that core\nand interferes with whoever is there.  The core timer IRQ is one issue,\nand the kthread scheduling is another.\n\nThat kthread scheduling issue is worse for ktasks, since they are long\nrunning.\n\nThis commit ensures that ktasks only run on core 0.  Eventually, we will\nprobably want ktasks to run on all sorts of cores - consider polling the\nNIC / driving the NAPI stack on a dedicated core.  The kernel alarm\nservice was briefly (out-of-tree) done with per-core ktasks.  For now,\nthink of ktasks as having affinity to core 0.\n\nThis is all a scheduling choice, so arguably we should be calling out to\nsched.c.\n\nSigned-off-by: Barret Rhoden \u003cbrho@cs.berkeley.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c5be33797f3278233b0d6a9891a4308fe20baba6",
      "old_mode": 33188,
      "old_path": "kern/src/kthread.c",
      "new_id": "4a9111b3321866b809dc1211aab64196185148c8",
      "new_mode": 33188,
      "new_path": "kern/src/kthread.c"
    }
  ]
}