lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Mar 2012 01:22:56 +0000 From: "Michael J. Wang" <mjwang@...adcom.com> To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> cc: "Michael J. Wang" <mjwang@...adcom.com> Subject: minor improvement to pick_next_highest_task_rt ? Hi RT Scheduler experts, I was studying pick_next_highest_task_rt() and was wondering if this is a valid improvement: --- rt.c-3.3-rc7 2012-03-15 17:53:27.774190199 -0700 +++ rt.c 2012-03-15 17:53:44.541979403 -0700 @@ -1403,7 +1403,7 @@ next_idx: if (idx >= MAX_RT_PRIO) continue; - if (next && next->prio < idx) + if (next && next->prio <= idx) continue; list_for_each_entry(rt_se, array->queue + idx, run_list) { struct task_struct *p; My reasoning is: if next is not NULL, then we have found a candidate task, and its priority is next->prio. Now we are looking for an even higher priority task in the other rt_rq's. idx is the highest priority in the current candidate rt_rq. In the current 3.3-rc7 code, if idx is equal to next->prio, we would start scanning the tasks in that rt_rq and replace the current candidate task with a task from that rt_rq. But the new task would only have a priority that is equal to our previous candidate task, so we have not advanced our goal of finding a higher prio task. So shouldn't we just skip that rt_rq if next->prio is less than *or equal to* idx ? I know this is just a minor improvement and probably results in no measurable performance gain. But it just seems more correct this way. (Or if it is not correct, maybe I'll learn something :-) I do not subscribe to the LKML (but I have read the FAQ), so I would appreciate it if you can cc me on your responses. Thanks, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists