)]}'
{
  "commit": "20b6331bfed1f07ba1e5006889a5d64adc53615e",
  "tree": "9a98f9ccd201c875a94f8a2002f1eddcfc114d65",
  "parents": [
    "f7d62364b2cef85cbcd4feffdd3632ef7c3b61c2"
  ],
  "author": {
    "name": "Dmitry Adamushko",
    "email": "dmitry.adamushko@gmail.com",
    "time": "Wed Jun 11 00:58:30 2008 +0200"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@elte.hu",
    "time": "Wed Jun 18 12:41:18 2008 +0200"
  },
  "message": "sched: rework of \"prioritize non-migratable tasks over migratable ones\"\n\nregarding this commit: 45c01e824991b2dd0a332e19efc4901acb31209f\n\nI think we can do it simpler. Please take a look at the patch below.\n\nInstead of having 2 separate arrays (which is + ~800 bytes on x86_32 and\ntwice so on x86_64), let\u0027s add \"exclusive\" (the ones that are bound to\nthis CPU) tasks to the head of the queue and \"shared\" ones -- to the\nend.\n\nIn case of a few newly woken up \"exclusive\" tasks, they are \u0027stacked\u0027\n(not queued as now), meaning that a task {i+1} is being placed in front\nof the previously woken up task {i}. But I don\u0027t think that this\nbehavior may cause any realistic problems.\n\nThere are a couple of changes on top of this one.\n\n(1) in check_preempt_curr_rt()\n\nI don\u0027t think there is a need for the \"pick_next_rt_entity(rq, \u0026rq-\u003ert)\n!\u003d \u0026rq-\u003ecurr-\u003ert\" check.\n\nenqueue_task_rt(p) and check_preempt_curr_rt() are always called one\nafter another with rq-\u003elock being held so the following check\n\"p-\u003ert.nr_cpus_allowed \u003d\u003d 1 \u0026\u0026 rq-\u003ecurr-\u003ert.nr_cpus_allowed !\u003d 1\" should\nbe enough (well, just its left part) to guarantee that \u0027p\u0027 has been\nqueued in front of the \u0027curr\u0027.\n\n(2) in set_cpus_allowed_rt()\n\nI don\u0027t thinks there is a need for requeue_task_rt() here.\n\nPerhaps, the only case when \u0027requeue\u0027 (+ reschedule) might be useful is\nas follows:\n\ni) weight \u003d\u003d 1 \u0026\u0026 cpu_isset(task_cpu(p), *new_mask)\n\ni.e. a task is being bound to this CPU);\n\nii) \u0027p\u0027 !\u003d rq-\u003ecurr\n\nbut here, \u0027p\u0027 has already been on this CPU for a while and was not\nmigrated. i.e. it\u0027s possible that \u0027rq-\u003ecurr\u0027 would not have high chances\nto be migrated right at this particular moment (although, has chance in\na bit longer term), should we allow it to be preempted.\n\nAnyway, I think we should not perhaps make it more complex trying to\naddress some rare corner cases. For instance, that\u0027s why a single queue\napproach would be preferable. Unless I\u0027m missing something obvious, this\napproach gives us similar functionality at lower cost.\n\nVerified only compilation-wise.\n\n(Almost)-Signed-off-by: Dmitry Adamushko \u003cdmitry.adamushko@gmail.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "554de40098037c8a115406c07036cfd751785cc3",
      "old_mode": 33188,
      "old_path": "kernel/sched.c",
      "new_id": "cc1d558406f8be937a696d80d321b0ee822b424c",
      "new_mode": 33188,
      "new_path": "kernel/sched.c"
    },
    {
      "type": "modify",
      "old_id": "8ae3416e0bb419ecc9fcb6ad5bf3cb699e1cf504",
      "old_mode": 33188,
      "old_path": "kernel/sched_rt.c",
      "new_id": "f721b52acd8d1bd1c4e547bc1f049983ff61920d",
      "new_mode": 33188,
      "new_path": "kernel/sched_rt.c"
    }
  ]
}