From: Jörn N. <net...@st...> - 2009-11-02 20:00:56
|
hi stefan! thanks for your valuable contribution. i hope i've understood it correctly. Stefan Richter wrote: > 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.) i've tried to work this into http://subversion.ffado.org/wiki/IrqPriorities. i'd appreciate if you and other ffado-devel patrons could verify it for correctness eventually. > 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. ok. i've noted that, but was reluctant to actually raise its priority. can anybody fill in this blank and add a good recommendation? maybe it should be somewhere between the audio-specific IRQs and the normal IRQs? then again, the default is 49, which is below any IRQs, so i don't know if raising it can mess things up... > 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 sounds interesting. however, i'm quite comfortable in the shallow end of the programmer's pool and would like to remain here for another year or so. and over yonder, it looks like there's fins sticking out of the water... -- Jörn Nettingsmeier Meister für Veranstaltungstechnik Audio and event engineer Ambisonic surround recordings http://stackingdwarves.net +49 177 7937487 |