tasklet 在用户空间应用程序中的优势
对下半部分有一些疑问。在这里，我只考虑小线程。 另外，我只考虑非抢占式内核。
假设考虑一个以太网驱动程序，其中 rx 中断处理正在执行大约 10 个函数调用。（糟糕的编程:)）
现在，从性能角度来看，如果 9 个函数调用可以移动到一个 tasklet，并且在中断处理中只需要调用 1 个，我真的可以在 TCP 读取应用程序中获得良好的性能吗？
或者换句话说，当切换到用户空间应用程序时，将调用调度的taskets的所有9个函数调用，实际上，只有在“所有调度的taskets”都被调用之后，用户空间应用程序才能够获取数据包和数据。完全的 ？正确的？
我知道通过拥有下半部，我们可以启用所有中断..但我怀疑依赖中断的应用程序是否真的通过在中断处理程序本身或下半部中拥有全部 10 个函数来获得任何东西。
简而言之，通过拥有tasklet，我可以在用户空间应用程序中获得性能改进吗？
Got some doubts with bottom half.Here, I consider tasklets only.
Also , I consider non-preemptible kernel only.
Suppose consider a ethernet driver in which rx interrupt processing is doing some 10 functions calls.(bad programming :) )
Now, looking at performance perspective if 9 function calls can be moved to a tasklet and only 1 needs to be called in interrupt handling , Can I really get some good performance in a tcp read application.
Or in other words, when there is switch to user space application all the 9 function calls for the tasklets scheduled will be called, in effective the user space application will be able to get the packet cum data only after "all the taskets scheduled" are completed ? correct?
I understand that by having bottom half , we are enabling all interrupts .. but I have a doubt whether the application that relies on the interrupt actually gain anything by having the entire 10 functions in interrupt handler itself or in the bottom half.
In Short, by having tasklet do I gain performance improvement in user space application ,here ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于微线程不是排队而是调度的，即发送同一个微线程的多个硬件中断可能会导致单个微线程函数调用，因此在极端情况下，您将能够节省高达 90% 的处理时间。
另一方面，net-rx 已经有一个高优先级的软 IRQ。
Since tasklets are not queued but scheduled, i.e. several hardware interrupts posting the same tasklet might result in a single tasklet function invocation, you would be able to save up to 90% of the processing in extreme cases.
On the other hand there's already a high-priority soft IRQ for net-rx.
根据我在快速机器上的经验，将工作从处理程序转移到微线程并不会使机器运行得更快。我在处理程序中添加了宏，可以将我的 Schedule_tasklet() 调用转换为对 tasklet 函数本身的调用，并且很容易对两种方式进行基准测试并查看差异。
但重要的是中断处理程序必须快速完成。正如 Nikolai 提到的，如果您的设备喜欢频繁中断，您可能会受益，但大多数高带宽设备都具有中断缓解硬件，这使得这个问题不那么严重。
使用tasklet 是核心内核人员做事的方式，所以在其他条件相同的情况下，最好跟随他们的领导，特别是如果您希望看到您的驱动程序被接受到主线内核中。
我还要指出的是，调用大量函数并不一定是不好的做法；现代分支预测器可以使分支密集的代码与非分支密集的代码运行得一样快。在我看来，更重要的是现在必须完成一半工作，然后再完成一半工作的潜在缓存效应。
In my experience on fast machines, moving work from the handler to the tasklet does not make the machine run faster. I've added macros in the handler that can turn my schedule_tasklet() call into a call to the tasklet function itself, and it's easy to benchmark both ways and see the difference.
But it's important that interrupt handlers finish quickly. As Nikolai mentioned, you might benefit if your device likes to interrupt a lot, but most high-bandwidth devices have interrupt mitigation hardware that makes this a less serious problem.
Using tasklets is the way that core kernel people are going to do things, so all else being equal, it's probably best to follow their lead, especially if you ever want to see your driver accepted into the mainline kernel.
I would also note that calling lots of functions isn't necessarily bad practice; modern branch predictors can make branch-heavy code run just as fast as non-branch-heavy code. Far more important in my opinion are the potential cache effects of having to do half the job now, and then half the job later.
Tasklet 不在用户进程的上下文中运行。如果您的 ISR 调度了一个 tasklet，它将在您的 ISR 完成后立即运行，但启用中断。这样做的好处是您的数据包处理不会阻止额外的中断。
在您的 TCP 示例中，硬件将数据包交给网络堆栈，并且您的驱动程序已完成 - 网络堆栈处理唤醒进程等，因此硬件驱动程序实际上无法在数据的进程上下文中执行收件人，因为硬件甚至不知道那是谁。
A tasklet does not run in context of the user process. If your ISR schedules a tasklet, it will run immediately after your isr is done, but with interrupts enabled. The benefit of this is that your packet processing is not preventing additional interrupts.
In your TCP example, the hardware hands off the packet to the network stack and your driver is done -- the net stack handles waking up the process etc. so there really no way for the hw's driver to execute in the process context of the data's recipient, because the hw doesn't even know who that is.