From: Stefan R. <st...@s5...> - 2009-11-01 17:20:39
|
Jörn Nettingsmeier wrote: > Stefan Richter wrote: [...] >> 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. > > is there a difference? can you explain? from my understanding, > "tasklets" are what used to be "bottom halves", i.e. the part of an irq > handler that actually deals with the work at hand, while the "top half" > only acknowledges the IRQ and then passes the work on to the bottom > half... but then, that's what i caught in passing, i'm not really in the > know. That's correct. Though more precisely, "tasklet" is one of the kernel's APIs for delayed execution. It happens to be the primary API used to implement bottom halves. (And vice versa, the primary use of this API is to implement bottom halves of interrupt handlers.) In case of the ieee1394 subsystem and firewire subsystem, interrupt event handling typically happens in three rather than two stages: The hardware interrupt service routine schedules a tasklet (for most types of interrupt event type, e.g. isochronous reception, asynchronous transmission...). In several cases, the tasklet then wakes up a kernel thread or a userspace process to do some more work. Of course it is subjective whether this third stage is still seen as part of interrupt handling; though functionally it is. The ieee1394 subsystem uses dedicated kernel threads for completion of outbound asynchronous transactions and for bus reset handling (bus management, device discovery). The firewire subsystem uses shared kernel threads for bus reset handling. So, those kernel threads are not interesting in terms of FireWire audio stream I/O. Audio I/O interrupt handling's third stage is FFADO/ Jack userspace. But back to your question: http://www.wil.cx/matthew/lca2003/paper.pdf gives a lot of background to how previous kernels did and AFAIU current mainline kernel still does operate. Fundamentally, there are three execution contexts: Interrupt, bottom half, process context. Tasklets and soft IRQs are normally executed in bottom half context; in case of high load they are shifted into a dedicated high priority process context. In the -rt kernel, almost everything but the very basic top halves was moved straight into process contexts. Still AFAIU. >> 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. > > what is IR and IT? Isochronous reception, isochronous transmission. >> 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. [I guessed this from the name of this -rt kernel thread. :-) ] [...] >> So, there are "hardware interrupts" (i.e. the IRQ handlers) and >> "software interrupts" (timer interrupts; in -rt apparently split into a [Correction: Soft IRQs and timer interrupts are different beasts.] >> 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. > > so you say that those things running in sirq-tasklet should be called a > tasklet? and all the [irq/foo] kernel threads are "IRQ handlers"? That's what I said yesterday; today I'd say it a bit differently. :-) "Interrupt handling" in the most abstract sense covers everything from hardware interrupt service routine (top half) through bottom half to corresponding processes. With "IRQ handler" a few lines above, I really only meant the hardware interrupt service routine (top half). "Tasklet" is a special term which refers to the most common (but not the only) form of implementation of bottom halves. OTOH, a tasklet can never implement a top half. I guess from the little which I read about -rt and from the names of the kernel threads which you listed, that the threads named [irq/...] took over the execution of the mainline kernel's drivers part of the top half, and the [sirq-...] took over the mainline's kernels bottom half execution contexts (soft IRQ and tasklet execution contexts). The tasklet kernel API apparently makes use of [sirq-tasklet/...] kernel threads. >> 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...) > > aren't all IRQs threaded by default on rt kernels? The drawback which I describe here, coming from the ohci1394 driver implementation, affects -rt this way: ohci1394 as well as many other drivers use the tasklet API to perform bottom halves. All of these tasklets are apparently injected into the [sirq-tasklet/...] thread of which there seem to be only as many as there are CPUs (CPU cores). Since ohci1394 isochronous receive tasklet and isochronous transmit tasklet sit between ohci1394's top half and FFADO/ Jack userspace, I conclude that latency of tasklet execution is important for audio latency. However, while -rt lets you control scheduling of ohci1394's top half and of FFADO/ Jack userspace specifically by means of scheduling class and scheduling priority of the corresponding dedicated kernel threads and userspace processes, you only have one global knob for the scheduling priority of any and all tasklets on the system. (Furthermore, ohci1394 I/O tasklets cannot preempt other tasklets on the same CPU core that might be less important to you.) Two possible solutions: - Get ohci1394 its own dedicated tasklet thread in -rt. I think this is unrealistic; the -rt maintainers would probably tell us to do the following instead. - Change ohci1394 (actually firewire-ohci, since we won't fundamentally change ohci1394 anymore) to _not_ use the tasklet API, at least for isochronous I/O. Instead use a process context (a kernel thread, or userspace where it makes sense). This could be one of the traditional kernel thread related APIs, notably the workqueue API, or the threaded interrupt handler API which is present in the mainline since 2.6.30: http://lwn.net/Articles/302043/ http://lxr.linux.no/#linux+v2.6.30/kernel/irq/manage.c#L831 -- Stefan Richter -=====-==--= =-== ----= http://arcgraph.de/sr/ |