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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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