kernel/sched.c bogon?

The comparisons of oldest_idle below trigger compiler warnings and should probably be safely type-cast:

Kip

Index: kernel/sched.c
===================================================================
RCS file: /home/cvs/linux/kernel/sched.c,v
retrieving revision 1.64.2.6
diff -u -r1.64.2.6 sched.c

sched.c 7 Mar 2003 00:57:35 -0000 renamed from sched.c 25 Feb 2003 22:03:13 -0000 1.64.2.6 +1 -1

@@ -282,7 +282,7 @@
                                target_tsk = tsk;
                        }
                } else {
-                       if (oldest_idle == -1ULL) {
+                       if (oldest_idle == (cycles_t) -1) {
                                int prio = preemption_goodness(tsk, p,
 cpu);
 

                                if (prio > max_prio) {

sched.c 7 Mar 2003 00:57:35 -0000 renamed from sched.c 25 Feb 2003 22:03:13 -0000 1.64.2.6 +1 -1

@@ -294,7 +294,7 @@
        }
        tsk = target_tsk;
        if (tsk) {
-               if (oldest_idle != -1ULL) {
+               if (oldest_idle != (cycles_t) -1) {
                        best_cpu = tsk->processor;
                        goto send_now_idle;
                }

I reported this bug last May. Apparently it is still not
taken up-stream. Ralf, why don't we fix it here and push
it up from you?

BTW, this bug actually has effect on real-time performance under preemptible kernel.

It can delay the execution of the highest
priority real-time process from execution up to 1 jiffy.

Quoted 6 lines · Jun Sun

I reported this bug last May. Apparently it is still not
taken up-stream. Ralf, why don't we fix it here and push
it up from you?

BTW, this bug actually has effect on real-time performance under preemptible kernel.

< = 2.4.x preemptible kernel is OPP.

Quoted 2 lines

It can delay the execution of the highest
priority real-time process from execution up to 1 jiffy.

Quite a number of users get_cycles() in the kernel assume it to return a 64-bit number. I guess we'll have to fake a 64-bit counter in software ...

Quoted 9 lines · Ralf Baechle

Quoted 6 lines · Jun Sun

I reported this bug last May. Apparently it is still not
taken up-stream. Ralf, why don't we fix it here and push
it up from you?

BTW, this bug actually has effect on real-time performance under preemptible kernel.

Quoted 8 lines

< = 2.4.x preemptible kernel is OPP.

Quoted 2 lines

It can delay the execution of the highest
priority real-time process from execution up to 1 jiffy.

Quite a number of users get_cycles() in the kernel assume it to return a 64-bit number. I guess we'll have to fake a 64-bit counter in software ...

Whether we fake 64-bit or not, oldest_idle is declared as cycles_t. So comparing it with (cycles_t)-1 should be always be correct. And it actually makes a correct C program. :-)

I don't see any possible reason for rejecting the change. My previous report is probably just lost in the noise.

The comparisons of oldest_idle below trigger compiler warnings and should probably be safely type-cast:

Kip

Index: kernel/sched.c
===================================================================
RCS file: /home/cvs/linux/kernel/sched.c,v
retrieving revision 1.64.2.6
diff -u -r1.64.2.6 sched.c

sched.c 7 Mar 2003 00:57:35 -0000 renamed from sched.c 25 Feb 2003 22:03:13 -0000 1.64.2.6 +1 -1

@@ -282,7 +282,7 @@
                                target_tsk = tsk;
                        }
                } else {
-                       if (oldest_idle == -1ULL) {
+                       if (oldest_idle == (cycles_t) -1) {
                                int prio = preemption_goodness(tsk, p,
 cpu);
 

                                if (prio > max_prio) {

sched.c 7 Mar 2003 00:57:35 -0000 renamed from sched.c 25 Feb 2003 22:03:13 -0000 1.64.2.6 +1 -1

@@ -294,7 +294,7 @@
        }
        tsk = target_tsk;
        if (tsk) {
-               if (oldest_idle != -1ULL) {
+               if (oldest_idle != (cycles_t) -1) {
                        best_cpu = tsk->processor;
                        goto send_now_idle;
                }