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/