Thomas Petazzoni wrote: > > There was a presentation on UIO in embedded systems at the latest > Embedded Linux Conference in April. The presentation includes a small > analysis of UIO's overhead with regard to interrupt latency. See > http://www.celinux.org/elc08_presentations/uio080417celfelc08.pdf
Bummer, on p. 20 it doesn't describe how the latency was measured. It also doesn't compare in-kernel measurements with equivalent UIO measurements. I don't particularly care what the interrupt latency is, if what is being measured is the time between when the interrupt is signaled to the CPU and the point at which the request_irq()-registered handler runs. Rather, most of the time I care more about how long it takes the kernel to wake up the process that's blocked in a wait_for_completion(), because I do most of my work outside of interrupt handlers (a characteristic of the devices and workloads I deal with, ymmv). In that case, the difference between in-kernel and UIO gets pretty small because the kernel activities at each interrupt are very similar, perhaps differing only by some cache activity. Glad they mention SCHED_[FIFO|RR], though. Without those, you're in for a pretty unpleasant UIO experience. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
