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/
- References:
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.51-12
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.51-12
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.51-12
- Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.51-12
[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]
|
|