lkml.org 
[lkml]   [2012]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subjectminor improvement to pick_next_highest_task_rt ?
Date
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




\
 
 \ /
  Last update: 2012-03-16 02:25    [W:0.036 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site