Messages in this thread | | | Date | Wed, 10 Feb 1999 14:51:54 +0100 | From | Peter Steiner <> | Subject | Re: Real Time scheduler? |
| |
In linux.dev.kernel, you wrote:
>>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/
| |