minor improvement to pick_next_highest_task_rt ?

minor improvement to pick_next_highest_task_rt ?

[Michael J. Wang]

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

Re: minor improvement to pick_next_highest_task_rt ?

[Yong Zhang]

Cc'ing more people.

And comments below.

On Fri, Mar 16, 2012 at 01:22:56AM +0000, Michael J. Wang wrote:
> 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 ?

Yeah, I think this make sense.

But you should remake your patch according to
Documentation/SubmittingPatches.

Thanks,
Yong

> 
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Only stand for myself

RE: minor improvement to pick_next_highest_task_rt ?

[Michael J. Wang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2578 bytes --]

Thanks Yong.  I will resend the patch according to Documentation/SubmittingPatches right after this.

Michael


-----Original Message-----
From: Yong Zhang [mailto:yong.zhang0@gmail.com] 
Sent: Sunday, March 18, 2012 11:32 PM
To: Michael J. Wang
Cc: linux-kernel@vger.kernel.org; Peter Zijlstra; Steven Rostedt; Ingo Molnar
Subject: Re: minor improvement to pick_next_highest_task_rt ?

Cc'ing more people.

And comments below.

On Fri, Mar 16, 2012 at 01:22:56AM +0000, Michael J. Wang wrote:
> 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 ?

Yeah, I think this make sense.

But you should remake your patch according to
Documentation/SubmittingPatches.

Thanks,
Yong

> 
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Only stand for myself

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥