Re: O(1) scheduler seems to lock up on sched_FIFO and sched_RR ta sks

["'joe.korty@ccur.com'" <joe.korty@ccur.com>]

> Hm!  I wonder.  Robert is working on a fix for schedsetschedule() 
> where it fails to actually tell the scheduler to switch to a process 
> that it just made higher priority or away from one it just lowered.
> 
> The net result is that the caller keeps running (FIFO for all in this 
> case) when, in fact it should have been switched out.  Next time 
> schedule() actually switches, it is all sorted out again.  Could the 
> elavation of the events/0 thread cause this needed switch?


I posted a fix for this a month ago that was ignored.  Which is a
good thing, since now that I look at it again, I don't care for the
approach I took nor does it appear to be complete.

Joe

----------- original posting

> Date: Wed, 21 May 2003 16:40:26 -0400
> From: Joe Korty <joe.korty@ccur.com>
> To: Ingo Molnar <mingo@elte.hu>
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH] setscheduler resched bug

setscheduler is not forcing a reschedule when needed like set_user_nice
does.  It should.

Joe


--- 2.5.69/kernel/sched.c.orig	2003-05-21 14:50:53.000000000 -0400
+++ 2.5.69/kernel/sched.c	2003-05-21 15:01:13.000000000 -0400
@@ -1716,6 +1716,7 @@
 	unsigned long flags;
 	runqueue_t *rq;
 	task_t *p;
+	int oldprio;
 
 	if (!param || pid < 0)
 		goto out_nounlock;
@@ -1778,12 +1779,20 @@
 	retval = 0;
 	p->policy = policy;
 	p->rt_priority = lp.sched_priority;
+	oldprio = p->prio;
 	if (policy != SCHED_NORMAL)
 		p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
 	else
 		p->prio = p->static_prio;
-	if (array)
+	if (array) {
 		__activate_task(p, task_rq(p));
+		/*
+		 * Reschedule if on a CPU and the priority dropped, or not on
+		 * a CPU and the priority rose above the currently running task.
+		 */
+		if ((rq->curr == p) ? (p->prio > oldprio) : (p->prio < rq->curr->prio))
+			resched_task(rq->curr);
+	}
 
 out_unlock:
 	task_rq_unlock(rq, &flags);