Messages in this thread | | | From | (Alan Cox) | Subject | Re: scheduling bottom halves/task queues | Date | Thu, 8 Apr 1999 01:00:47 +0100 (BST) |
| |
> 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
You can almost never manage this.
> significant challenge, as it could involve modifying all of > device drivers that we would be interested in creating this
You need to read the vm and the block driver layer too. Tasks end up flushing pages for each other for example.
> blocking call (the professor used the example of when it > requests a disk block) and then try to match up a process to
But that block request will be merged by the scsi layer into a scatter gather list with 12 other peoples requests, then the return will come out of order due to tagged queueing. At some point you should realise someone has loaded the dice. We won't get into atomic_bh locking and priority inversion 8)
> 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.
In an environment with fast real time schedulers, and good hard RT guarantees perhaps instead of playing a losing game with BH handlers you should think about making bottom halves very real time tasks - KURT then at least owns the problem. Since BH handlers are atomic w.r.t themselves and each other, the bh running becomes a check and a schedule of the bh rt task
Alan
- 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/
| |