微线程在用户空间应用程序中的优势

Question

对底层half.Here有一些疑问，我只考虑微线程。另外，我只考虑不可抢占的内核。

假设有一个以太网驱动程序，其中rx中断处理正在执行大约10个函数调用。(糟糕的编程:)

现在，从性能的角度来看，如果9个函数调用可以移动到一个微线程，而在中断处理中只需要调用1个，那么我真的能在tcp读取应用程序中获得良好的性能吗？

或者换句话说，当切换到用户空间应用程序时，调度的微线程的所有9个函数调用都将被调用，实际上用户空间应用程序只有在“所有调度的任务”完成后才能获得数据包和数据？对，是这样?

我知道，通过使用下半部分，我们可以启用所有中断。但我怀疑依赖于中断的应用程序是否通过将全部10个函数放在中断处理程序本身或下半部分中而真正获得了什么。

简而言之，通过使用微线程，我是否在用户空间应用程序中获得了性能改进？

Answer 1

由于微线程不是排队而是调度的，即发布相同微线程的几个硬件中断可能会导致单个微线程函数调用，因此在极端情况下，您将能够节省高达90%的处理。

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

Answer 2

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

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

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

我还会注意到，调用大量函数并不一定是糟糕的做法；现代分支预测器可以使分支繁重的代码运行得与非分支繁重的代码一样快。在我看来，更重要的是现在必须完成一半工作，然后再完成一半工作的潜在缓存效应。

Answer 3

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

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