Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.51-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On Sat, 2005-07-09 at 23:24 +0200, Peter Zijlstra wrote:
> On Fri, 2005-07-08 at 13:12 -0700, William Weston wrote:
> > On Fri, 8 Jul 2005, Ingo Molnar wrote:
> > 
> > > could you check whether the priority leakage happens if you disable SMP?  
> > > (if you can reproduce it easily)
> > 
> > No priority leakages have been seen with UP configs on any of the 
> > machines I've been testing.
> > 
> > The leakage is not hard to reproduce under SMT:  start up jackd from a
> > text vc with an rt prio of 60 (or some unique prio above the IRQ threads),
> > then restart X and login.  After several minutes, X and all of its
> > children will be running at whatever prio jackd was started at (but still
> > SCHED_NORMAL).  Eventually, init, a handful of SCHED_NORMAL kernel
> > threads, and other random processes are all running at the same priority.  
> > When reset to default priority with chrt or schedtool, these processes
> > eventually revert back to the leaked priority level.  When jackd is
> > stopped, the priorities stay in their elevated state.  If jackd is not 
> > started before logging in to X, then the priority of one of the SCHED_FF 
> > kernel threads is leaked to other processes in the same manner.
> > 
> 
> I can reproduce priority leakage on my SMP system; any userspace process
> chrt'ed up and a lot will follow. This makes the system very
> unresponsive when doing a make -j5. Verified on 51-{6,18,23}.
> 

The following patch seems to fix it for me, YMMV.

--- kernel/sched.c~     2005-07-08 10:27:59.000000000 +0200
+++ kernel/sched.c      2005-07-10 13:00:42.000000000 +0200
@@ -780,7 +780,8 @@ static void recalc_task_prio(task_t *p,
                }
        }

-       p->prio = p->normal_prio = effective_prio(p);
+       p->prio = effective_prio(p);
+       p->normal_prio = unlikely(rt_prio(p->normal_prio)) ? p->prio : __effective_prio(p);
 }

 /*
@@ -1415,7 +1416,8 @@ void fastcall wake_up_new_task(task_t *
        p->sleep_avg = JIFFIES_TO_NS(CURRENT_BONUS(p) *
                CHILD_PENALTY / 100 * MAX_SLEEP_AVG / MAX_BONUS);

-       p->prio = p->normal_prio = effective_prio(p);
+       p->prio = effective_prio(p);
+       p->normal_prio = unlikely(rt_prio(p->normal_prio)) ? p->prio : __effective_prio(p);

        if (likely(cpu == this_cpu)) {
                if (!(clone_flags & CLONE_VM)) {
@@ -1427,7 +1429,8 @@ void fastcall wake_up_new_task(task_t *
                        if (unlikely(!current->array))
                                __activate_task(p, rq);
                        else {
-                               p->prio = p->normal_prio = current->prio;
+                               p->prio = current->prio;
+                               p->normal_prio = current->normal_prio;
                                __activate_task_after(p, current, rq);
                        }
                        set_need_resched();
@@ -2744,7 +2747,8 @@ void scheduler_tick(void)
        if (!--p->time_slice) {
                dequeue_task(p, rq->active);
                set_tsk_need_resched(p);
-               p->prio = p->normal_prio = effective_prio(p);
+               p->prio = effective_prio(p);
+               p->normal_prio = unlikely(rt_prio(p->normal_prio)) ? p->prio : __effective_prio(p);
                p->time_slice = task_timeslice(p);
                p->first_time_slice = 0;



-- 
Peter Zijlstra <[email protected]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux