On Thu, 22 Jun 2006, Thomas Gleixner wrote:
On Thu, 2006-06-22 at 19:06 +0100, Esben Nielsen wrote:
Thats a seperate issue. Though you are right.
Why not use my original patch and solve both issues?
I have even updated it to avoid the double traversal. It also removes
one other traversal which shouldn't be needed. (I have not had time
to boot the kernel with it, though, but it does compile...:-)
Let me comment on your last sentence first:
We want an immidate propagation.
There is no such thing as "immidiate". The most you can say is that when
you return from setscheduler() everything is taken care off. I agree - it
has to be like that. But I just want to add _effectively_ taken care off. I.e.
when the within the time setscheduler() has returned _and_ the the
relevant priorities have time to run things get fixed. No, the users
should not have to worry about the priorities hanging around, but the
system can wait with fixing them it is relavant.
Simply because it does not solve following scenario:
High prio task is blocked on lock and boosts 3 other tasks. Now the
higher prrio watchdog detects that the high prio task is stuck and
lowers the priority. You can wake it up as long as you want, the boosted
task is still busy looping.
Yes, you are right. I have thought about how to fix it, but it will be
rather ugly. I'll try to see what I can do though, but I am afraid the
patch might get too big. :-(
(
The same problem may actually always have been present in another corner
situation:
A boosts B whichs is blocked interruptible on a lock a boosts C, which
again boosts D (etc.). A and B are signalled roughly at the same time. A
wakes up first a decrease the priority of B but not C, because the B runs
on another CPU, but with lower priority and fixes C. A then stops because C is
fixed. but D still have the A's priority and preempts B, which should fix
it, but has it's low priority back.
This situation is not bad because A has already been in the and
therefore the designer has to think that C D etc already got it's
priority. That A is later on interrupted shouldn't matter.
)
May I suggest a compromise:
if (in_interrupt() ||
( increasing priority && current->prio < prio ) )
do it Esben's way;
else
do it Thomas's way;
Then will have fixed most of the problems. We still have the problem of a
the high priority watchdog task being unbound in setscheduler(), though.
And if it is called from interrupt and used to descrease the priority, it
wont work correctly. But it will work for the use in hrtimers, where the
priority is increased from interrupt.
And I do not like the idea of invoking the scheduler to do those
propagations. setscheduler is a synchronous effect in all other cases.
So it has to be synchronous in the propagation case too.
See my note above about being "immediate". Syncronous is more precise but
the same argument holds.
Preempt-RT and the dynamic priority adjustment of high resolution timers
is a different playground and we have to think about that seperately.
*nod*
I agree, although we deffinitely don't want to have too many #ifdef
CONFIG_PREEMPT_RT around in the code. That makes it far harder to get into
the mainline tree.
I was bonked for using the other thread for preempt-realtime stuff, so I
assume this thread is for preempt-realtime stuff only :-)
tglx
-
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]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
