lkml.org 
[lkml]   [1999]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: scheduling bottom halves/task queues
Date
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.055 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site