Messages in this thread | | | From | pwhiting@fury ... | Date | Wed, 7 Apr 1999 16:41:17 -0500 | Subject | scheduling bottom halves/task queues |
| |
A professor I am working with has asked me to attempt to make bottom-halves (and task queues nodes) schedulable. I wanted to pose the general question to this group and determine if any similar work has been done, if there is a sane approach to the problem, and if it might be generally useful.
First, some background. The University of Kansas (KU) has been researching real-time systems and has produced a linux kernel mod they call KURT (KU Real Time). Various experiments with this system have demonstrated that it is a capable real-time system. However, there remains at least one major source of distortion in the real-time scheduler - the bottom half handler. Various approaches have been taken to address this.
One student determined the bottom half causing the most trouble was the SCSI driver, as it would queue up 10-20 chunks of work. He simply broke that chain such that each chunk was treated individually and reduced the scheduling distortion. (I don't have a lot of info on his work - but if someone wants details I will dig them up.)
A different approach taken by another student was to modify the loop in which the active bottom halves were being executed to take a look at the current time-line. If too much time had elapsed in the BH handler, BH processing would terminate and control would return to the scheduler. (As before, I don't have all of the details on this yet.)
The professor I am working with would like to take this a step (many steps?) further by associating (when possible) work being done by a bottom half (or tqueue node) with the process for which it is being done. This might be a significant challenge, as it could involve modifying all of device drivers that we would be interested in creating this behavior for. Further, I am not certain we can always figure out which process a particular bottom half is "working for" until the very end. We could attach some information to the task struct when the process makes a blocking call (the professor used the example of when it requests a disk block) and then try to match up a process to an interrupt in the ISR. This might be cumbersome. Perhaps a bottom quarter to figure out who the work belongs... To sum up, he would like to have the bottom halves execute in the context of the process that gave rise to their existence (when such a process exists.) Matching up seems to be the hard task here. Do you see any reasons this might be easy/hard, doable/impossible, good idea/bad idea?
I was proposing some slightly (?) easier approaches with the goal of reducing the distortion caused by the bottom halves. One might be to allow the scheduler to determine which process it would like to run next prior to running the bottom halves and if this process is a RT task, run the RT task instead of the bottom half handler. Whenever the bottom half handler would run it could return control to the scheduler between executing each of the 32 bhs (or between each node in the task queue). The scheduler could repeat the above decision. This is an ugly performance hit, so it would need some knobs to turn it off in the absence of RT processing. It might also have some unfortunate side effects if multiple RT processes are running and one gets blocked for some IO... Perhaps in the event a RT process was blocked the BHs could execute more frequently. Further, some BHs might need to execute regardless - perhaps the timer tqueue.
A comment regarding KURT is in order - its RT scheduler is using an explicit schedule where RT processes are executed according to some pre-requested period - the "spare" time can be used to service non-RT processes, and in my case, bottom-halves. More info on KURT is available at: http://hegel.ittc.ukans.edu/projects/kurt/index.html
Another approach would be to have the scheduler pass the bottom half handler the maximum time it can spend based on who will run next and when they need to run. This would avoid re-running the scheduler frequently but it might ignore the case when a RT process blocked at the beginning gets made runable by a BH and needs to be scheduled in prior to the rest of the BHs completing.
comments/ideas/mockery?
pete
- 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/
| |