> pseudo-interrupt from user space

There's nothing pseudo about it. Again, any usual way to have a userspace
application respond to an interrupt will be the exact same. The kernel will
block the userspace process until the interrupt is seen. The only real
alternative is burning up the cpu with memory polling, which appears to be
what the BBIOlib method uses. So, your latency is limited to your poll
speed (which can be faster than interrupts). But, if you have a constant
poll for minimum latency, lets hope you're not trying to do something
important elsewhere since your cpu usage will be at 100%, and you'll be
maximizing process to process context switching!

For 4, The only difference between a userspace and kernel space interrupt
handler is where the code is that responds to the interrupt. You will only
benefit from writing your own interrupt handler if you put all of your code
that does something with that interrupt in the kernel. Otherwise, you're
back to process blocked by kernel, interrupt occurs, kernel unblocks
process, process does something after seeing the interrupt....back to the
sysfs/UIO method.

I would try some benchmarks. See if the regular UIO/sysfs interrupt method
gives you sufficient performance. And definitely keep in mind John's
statement. You're going to see a massive amount of jitter for anything in
userspace or kernel space (better jitter since you can disable interrupts
and whatnot, but if you don't finish quickly in kernel space, you'll crash
the kernel).

If something like a precise timestamp is needed for an async event, then
there are other ways to approach this. If you're looking for fixed low
latency, you're doomed.

On Wed, Sep 10, 2014 at 5:13 AM, neo <prag.in...@gmail.com> wrote:

> pseudo-interrupt from user space

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to