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

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