对下半部分有一些疑问。在这里，我只考虑小任务。另外，我只考虑非抢占式内核。
假设考虑一个以太网驱动程序，其中 rx 中断处理正在执行大约 10 个函数调用。（糟糕的编程:)）
现在，从性能的角度来看，如果可以将 9 个函数调用移动到一个 tasklet 并且只需要在中断处理中调用 1 个，那么我真的可以在 tcp 读取应用程序中获得一些好的性能吗？
或者换句话说，当切换到用户空间应用程序时，所有调度的小任务的9个函数调用都会被调用，实际上用户空间应用程序只有在“所有已调度的任务”完成后才能获取数据包和数据完全的 ？正确的？
我知道通过设置 bottom half ，我们启用了所有中断 .. 但我怀疑依赖中断的应用程序是否真的通过在中断处理程序本身或下半部分中拥有整个 10 个函数来获得任何东西。
简而言之，通过使用 tasklet，我可以在用户空间应用程序中获得性能改进吗？
由于 tasklet 不是排队而是计划的，即多个硬件中断发布同一个 tasklet 可能会导致单个 tasklet 函数调用，因此在极端情况下 您将能够节省高达 90%的处理。
另一方面，已经有一个用于 net-rx 的高优先级软 IRQ。
根据我在快速机器上的经验，将工作从处理程序转移到 tasklet 不会使机器运行得更快。我在处理程序中添加了宏，可以将我的 schedule_tasklet() 调用转换为对 tasklet 函数本身的调用，并且很容易对两种方式进行基准测试并查看差异。
但重要的是中断处理程序能够快速完成。正如 Nikolai 所提到的，如果您的设备喜欢大量中断，您可能会受益，但大多数高带宽设备都有中断缓解硬件，这使得这个问题不那么严重。
使用 tasklet 是核心内核人员做事的方式，所以在其他条件相同的情况下，最好跟随他们的领导，特别是如果您希望看到您的驱动程序被主线内核接受。
我还要注意，调用大量函数不一定是不好的做法。现代分支预测器可以使分支繁重的代码与非分支繁重的代码一样快。在我看来，更重要的是现在必须完成一半工作，然后再做一半工作的潜在缓存效应。
tasklet 不在用户进程的上下文中运行。如果您的 ISR 安排了一个 tasklet，它将在您的 isr 完成后立即运行，但启用了中断。这样做的好处是您的数据包处理不会阻止额外的中断。
在您的 TCP 示例中，硬件将数据包传递给网络堆栈并且您的驱动程序已完成 - 网络堆栈处理唤醒进程等，因此硬件驱动程序实际上无法在数据的进程上下文中执行收件人，因为硬件甚至不知道那是谁。