用户空间应用程序中的tasklet优势

Question

对下半部分有些怀疑。在这里，我只考虑了tasklet。 另外，我只考虑不可抢占的内核。

假设考虑一个以太网驱动程序，其中rx中断处理正在执行大约10个函数调用。（编程错误:)）

现在，从性能角度来看如果9个函数调用可以移动到tasklet并且只需要在中断处理中调用1个，那么我是否真的可以在tcp读取应用程序中获得一些好的性能。

或者换句话说，当切换到用户空间应用程序时，将调用所有调度的tasklet的9个函数调用，在有效的情况下，用户空间应用程序将只能在“所有任务”之后获取数据包和数据预定“已完成？正确的吗？

我理解通过下半部分，我们正在启用所有中断..但我怀疑依赖于中断的应用程序是否通过在中断处理程序本身或下半部分中使用整个10个函数来获得任何东西。

简而言之，通过使用tasklet，我可以在这里获得用户空间应用程序的性能提升吗？

Answer 1

由于tasklet没有排队但已调度，即发布相同tasklet的多个硬件中断可能导致单个tasklet函数调用，因此您可以在极端情况下保存最多90％的处理案例。

另一方面，net-rx已经有一个高优先级的软IRQ。

Answer 2

根据我在快速机器上的经验，将工作从处理程序移动到tasklet不会使机器运行得更快。我在处理程序中添加了宏，可以将我的schedule_tasklet（）调用转换为对tasklet函数本身的调用，并且很容易对这两种方式进行基准测试并看到差异。

但是中断处理程序快速完成很重要。正如Nikolai所说，如果你的设备喜欢中断很多，你可能会受益，但是大多数高带宽设备都有中断缓解硬件，这使得这个问题不那么严重。

使用tasklet是核心内核人员做事的方式，所以在其他条件相同的情况下，最好跟随他们的领先，特别是如果你想看到你的驱动程序被接受到主线内核中。

我还要注意，调用很多功能并不一定是不好的做法;现代分支预测器可以使分支繁重的代码运行与非分支密集代码一样快。在我看来，更重要的是现在不得不完成一半工作的潜在缓存效应，然后是工作的一半。

Answer 3

tasklet不会在用户进程的上下文中运行。如果您的ISR安排了一个tasklet，它将在您的isr完成后立即运行，但启用了中断。这样做的好处是您的数据包处理不会阻止其他中断。

在您的TCP示例中，硬件将数据包交给网络堆栈并且您的驱动程序已完成 - 网络堆栈处理唤醒进程等因此hw的驱动程序无法在进程上下文中执行数据的收件人，因为hw甚至不知道是谁。