15

I am developing a system with a DSP and an ARM. On the ARM there is a linux OS. I have a DSP sending data to the ARM (Linux) - In the Linux there is a kernel module which read the data received from the DSP. The kernel module is waking up to read the data, using an hardware interrupt between the DSP to the ARM.

I want to write a user space app, that will read the data from the kernel space (The kernel module) each time there's a new data arrived from the DSP.
The question is:

What is better approach to do that, a software interrupt from the kernel to the user-space or polling from the user-space (reading a known memory address with the kernel) every 10ms..?

Knowing that:

  • The data from the DSP to the kernel must arrive in very short time - 100us.
  • The data from the kernel to the user-space can take 10ms to 30ms.
  • The data that is being read is regarded small - around 100 bytes.
n0p
  • 3,399
  • 2
  • 29
  • 50
Gold Fish
  • 445
  • 6
  • 16
  • 1
    Kinda depends on your application... Can you give us a few more parameters about what you're doing with the notification of data, what time constraints that code is under? – Joe Mar 26 '14 at 13:43
  • 1
    About reading a known memory address in the kernel, don't do that! Look at how other devices works: They let user-space application open a file-descriptor that the application then can read the data from. You might also want to look at how other (similar) devices handle notifications/polling. – Some programmer dude Mar 26 '14 at 13:46
  • What's your latency requirement? What's your power constraint? – WiSaGaN Mar 26 '14 at 13:46
  • 1
    It's usual to set a semaphore from the driver - the user-space thread waits on it, the driver signals it and asks for a reschedule on exit.. Polling is just wasteful and latency-inducing. – Martin James Mar 26 '14 at 13:48
  • I updated the question with time latency and the size of the data.. – Gold Fish Mar 26 '14 at 13:50
  • I have a same task. Can you tell how you solved the problem? – Artem Romanov Feb 24 '16 at 07:03

3 Answers3

13

I would create a device and have the userland program block on read. No need to wait 10ms in between, this is handled efficiently by blocking.

Polling in a sense of using poll (yes, I understood that's not what you meant) would work fine, but there is no reason to call two functions (first poll and then read) when one function can do it anyway. No need to do it every 10ms, you can immediately call poll again after having processed what you got from your last read.

Polling in a sense of checking a known memory location every 10ms is not advisable. Not only is this an ugly hack and more complicated than you think (you will have to map the page containing that memory location to user space), and a form of busy waiting which needlessly consumes CPU, it also has an average latency of 5ms and a worst case latency of 10ms, which is entirely unnecessary. Average and worst case latency of read is approximately zero (well, not quite, but nearly so... it's as fast as waking a blocked task goes).

Interrupts (i.e. signals) are very efficient but make the program a lot more complicated/contorted compared to simply reading and blocking (have to write a signal handler, may not use certain functions in handlers, must communicate to main app, etc.). While technically a good solution, I would advise against them because a program needs not be more complicated than necessary.

Damon
  • 67,688
  • 20
  • 135
  • 185
1

Polling has no advantage over waiting. The process still has to be scheduled and switched to and all that and then it does useless poll part of the time.

Linux runs scheduler when returning from interrupts, so when you wake up the waiting task in the in-kernel interrupt handler and it has high priority set (you should give it real-time priority, obviously) the task will be scheduled immediately. You won't beat that with polling.

The standard interface of (character) device files is reasonably fast, so just implement blocking read, poll (which is a blocking system call, not polling anything really) and possibly asynchronous read (uses real-time signal), but I suspect performance of dedicated thread waiting in read system call will be better than AIO. And it's easier to write too. You should find enough examples in kernel sources.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
0

You don't seem to mention any hard time constraints, so you could really go with either approach. However, as Martin James said, polling introduces some overhead to the application, which you probably don't want.

Personally, I'd go with an interrupt or event flag triggered by the kernel. While you may not have have hard timing constraints, I assume you're wanting something that's more deterministic, rather than not. A kernel interrupt will get you closer to that.

dsell002
  • 1,296
  • 2
  • 11
  • 24