>>the processor, e.g. when there's a process running at nice=0 then no
>>proces with nice=11 or higher will get the cpu. On the other hand, if
>
>As I just pointed out for the SCHED_IDLE patch: doing that, you open a
>window to deadlocking on semaphores.
Yes, I know. The patch needs to be enhanced/corrected. From what I read
in this thread it seems a fix to that priority inversion (high priority
processes temporarily inherit the low priority of the holder of the
lock) would be good anyway, even for the current scheduler.
>To fix this properly (as pointed out by Pavel) you must be more clever and
>see _where_ the process got rescheduled.
I like the idea to temporarily increase the priority of the lock holder
as mentiond in this thread, but I don't know how to do. All I can think
of has bad races and slows things down.
>>+ if (p->policy != SCHED_OTHER ||
>>+ p->counter+(p->priority<<2)>=current->counter+(current->priority<<2)) {
>
> `p->counter + p->priority > current->counter + 3 + p->priority'
You mean `p->counter + p->priority > current->counter + 3 + current->priority'?
>This make sense to me since we may want to reschedule the current task if
>the wokenup one has very higer priority.
That's basically what I do. I just omitted the + 3 and scaled the
p->priority
The +3 disappeared because I want to help freshly woken-up processes to get
the CPU. This still doesn't work very well and needs further
modification of goodness().
I do that scaling to keep p->counter and p->priority in their usual
ranges while having a range of 11 niceness-values getting the CPU.
(10<<2 = 40 and current->counter = [0..40])
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/