take a look at:
J. C. Mogul, K. K. Ramakrishnan, "Eliminating Receive Livelock in an
Interrupt-driven Kernel," Proceedings of USENIX Technical
Conference, January 1996.
and
G. Banga, P. Drushel, J. C. Mogul, "Better operating system features for
faster network servers," SIGMETRICS Workshop on Internet
Server Performance, June 1998.
[ actually there's a more recent paper on resource containers but i don't
think it's been published yet ]
good luck...
On Wed, 7 Apr 1999 pwhiting@fury.ittc.ukans.edu wrote:
> 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.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/citi-netscape/
- 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/