Messages in this thread | | | Date | Wed, 10 Feb 1999 16:07:26 +0100 | From | Peter Steiner <> | Subject | Re: Real Time scheduler? |
| |
>Consider Process 0 ... 255 share a 1000 file descriptors in some
Hmm, I don't understand that example. I'm not an expert in this so correct me if I'm wrong:
You have a low priority process P0 waiting on FD{0}.
Then high priority P1 also waits on FD{0}. I guess there's no priority queue, so first P0 gets unlocked and then P1? In this case P0 must inherit the priority of P1. A process P2 would have to check P1 and P0 and maybe adjust their priority etc.
When P0 leaves for whatever reason it simply gets it's original priority back. What do you want to recalculate here in P1 or P2?
You don't have that problem if the queue gets reorderd by priority, since then P0 wouldn't get a higher priority at all. The only situation where P0 needs to get higher priority is when it actually got the lock and tries to continue execution. In this case it needs to inherit the priority of the first process in the queue until it reaches the unlock.
>And then consider how a kernel that depends on the operation of many daemon >processes will continue to operate when users can introduce arbitrarily many >"RT" processes that can block daemons indefinitely.
Users can only lower priority.
The easiest solution seems to be to give all processes at least a small minimum timeslice and to not inherit anything. Then things basically work like they already work. Just that nice processes will be much nicer than currently.
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/
| |