From: Stefan R. <st...@s5...> - 2009-10-31 13:27:32
|
Jörn Nettingsmeier wrote: > hi everyone! > > bored on a train, part 2: > > http://subversion.ffado.org/wiki/IrqPriorities > > still needs some additions, notably the rtirq section is out of date. > please comment, and can anyone explain to me why rtc0 should have > maximum priority? please also critically review the assumptions i made > about the order of tasklets. [Disclaimer: I only superficially know how -rt differs from mainline from what I read at lwn.net and never used -rt myself.] I wonder about nomenclature on the wiki page. In the preamble, "Since most of the actual work that has to be done to respond to an IRQ is done in a tasklet, one should also ensure that the priority of the softirq-tasklet processes is high enough. Otherwise tasklets are not executed in time." sounds correct. However, in section '2. Find out which processes handle the IRQs' and '3. Set the tasklet priorities', there is talk about "IRQ tasklets", and IRQ handler threads and soft-IRQ threads are lumped together. The driver implementation is that ohci1394's IRQ handler thread executes only the minimal ohci_irq_handler() function which reads and writes the controller's IRQ event registers and schedules e.g. IR and IT tasklets for execution. Tasklets on the other hand are work items which are performed in the context of a soft-IRQ thread --- I guess that's [sirq-tasklet/#], where # is presumably the CPU which also executes the OHCI 1394 controller's IRQ handler. So, there are "hardware interrupts" (i.e. the IRQ handlers) and "software interrupts" (timer interrupts; in -rt apparently split into a few more or less special-purpose threads. From the listings at your wiki page it appears that -rt creates one soft-IRQ thread per CPU (per core) as a catch-all tasklet execution thread ("tasklet" = a work item to be done at the next opportunity). So, I think a terminology like "IRQ handlers" on one hand and "tasklets" or "soft IRQs" on the other hand should be used. Regarding how to set IRQ priorities: The current implementation obviously has the drawback that ohci1394 uses the tasklet API together with a number of other kernel subsystems. (Ditto the firewire-ohci driver.) Thus you have no means to e.g. prioritize FireWire IR and IT jobs over whatever other tasklets the system might run (and vice versa, possibly prioritize whatever fundamental other system tasklets over FireWire IR and IT jobs). The way out is probably to switch firewire-ohci to the threaded IRQ handler API which is now already available in mainline Linux and move the tasklets into the IRQ handler. (This is to be done after somebody fixed basic IR/IT of the firewire-ohci + firewire-core + libraw1394 + ffado stack of course... unless the firewire-ohci + ~-core + ALSA streaming interface driver + ffado work is finished even before that...) Besides the currently close-to-zero speed of FFADO-targeted kernel driver development (sorry for that; I somehow need to get back some free time for driver hacking), there might be more challenges: - How will mainline kernel's (and mainstream distro kernels') FireWire I/O performance turn out if the firewire stack starts using an IRQ handler thread while some other subsystems still don't for some time? - It may be desirable or necessary to reorganize the subystem's controller event handling further --- move some of what is currently a tasklet into a different context than the IRQ handler thread; vice versa move some work which is currently done outside tasklets into the IRQ handler thread... -- Stefan Richter -=====-==--= =-=- ===== http://arcgraph.de/sr/ |