Linux中断与轮询 [英] Linux Interrupt vs. Polling

查看:304
本文介绍了Linux中断与轮询的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发带有DSP和ARM的系统.在ARM上有一个Linux OS.我有一个DSP将数据发送到ARM(Linux)-在Linux中,有一个内核模块可以读取从DSP接收的数据.内核模块正在唤醒,以使用DSP与ARM之间的硬件中断来读取数据.

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.

我想编写一个用户空间应用程序,每次从DSP收到新数据时,该应用程序将从内核空间(内核模块)读取数据.
问题是:

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:

什么是更好的方法呢?每10毫秒从内核到用户空间的软件中断或从用户空间的轮询(用内核读取一个已知的内存地址).

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..?

知道:

  • 从DSP到内核的数据必须在很短的时间内到达-100us.
  • 从内核到用户空间的数据可能需要10到30毫秒.
  • 正在读取的数据被认为很小-大约100个字节.

推荐答案

我将创建一个设备,并将用户界面程序块放在read上.无需等待10ms,这可以通过阻塞有效地处理.

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.

从某种意义上讲,使用poll进行轮询(是的,我明白这不是您的意思)可以正常工作,但是当一个函数调用一个函数时,没有理由调用两个函数(首先是poll然后是read)仍然可以做到.无需每10毫秒执行一次,您可以在处理完上次读取的内容后立即再次调用poll.

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.

建议每10毫秒检查一次已知的内存位置,以进行轮询.这不仅是一个丑陋的黑客,而且比您想象的要复杂(您必须将包含该内存位置的页面映射到用户空间),并且是一种不必要地占用CPU的繁忙等待形式,它的平均延迟为5毫秒,最坏的情况是10ms的延迟,这完全没有必要. 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.

这篇关于Linux中断与轮询的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆