Linux softirq 和 tasklet 在哪个上下文中？

Which context are softirq and tasklet in?

提问by kai

I know that there are process context and interrupt context but I don't understand when executing softirq or tasklet, which context is it run under.

我知道有进程上下文和中断上下文，但我不明白在执行 softirq 或 tasklet 时，它在哪个上下文下运行。

I have seen some people use the term "bottom-halves context", if there's such term, what's the difference comparing with the others.

我看到有些人使用术语“下半部分上下文”，如果有这样的术语，与其他术语相比有什么区别。

Another question to softirq and tasklet is that why sleep are not allowed during execution??

softirq 和 tasklet 的另一个问题是，为什么在执行期间不允许睡眠？

Can anyone help me identify these questions, thanks!!

谁能帮我找出这些问题，谢谢！！

采纳答案by kai

The softirq and tasklet are both kind of bottom-halves mechanism. Sleep is not allowed becuase they run under interrupt context not process context. If sleep is allowed, then the linux cannot schedule them and finally cause a kernel panic with a dequeue_task error. The interrupt context does not even have a data structure describing the register info, so they can never be scheduled by linux. If it is designed to have that structure and can be scheduled, the performance for interrupt handling process will be effected.

softirq 和 tasklet 都是一种底层机制。睡眠是不允许的，因为它们在中断上下文而不是进程上下文下运行。如果允许睡眠，则 linux 无法安排它们并最终导致内核崩溃并出现 dequeue_task 错误。中断上下文甚至没有描述寄存器信息的数据结构，因此它们永远不会被 linux 调度。如果设计成具有这种结构并且可以调度，则中断处理过程的性能将受到影响。

回答by kaiwan

@kai: your qs reg which context bottom-halves execute in?

@kai：你的 qs reg 在哪个上下文下半部分执行？

Technically, softirq's dorun in an interrupt context - the "softirq" context; it's just that it's not "hard-irq" context (which is the context when a hardware interrupt occurs).

从技术上讲，软中断确实在中断上下文中运行——“软中断”上下文；只是它不是“硬中断”上下文（这是发生硬件中断时的上下文）。

So, in a softirq handler, in terms of the 'lookup' macros Linux provides:

因此，在软中断处理程序中，就 Linux 提供的“查找”宏而言：

in_interrupt: yes | in_irq: no | in_softirq: yes | in_serving_softirq: yes

in_interrupt: 是 | in_irq: 没有 | in_softirq: 是 | in_serving_softirq: 是

But be aware (beware!!! :): "all of the restrictions that apply to interrupt handlers also apply to bottom halves. Thus, bottom halves cannot sleep, cannot access user space, and cannot invoke the scheduler." -- LDD3.

但请注意（注意！！！:)：“适用于中断处理程序的所有限制也适用于下半部分。因此，下半部分不能休眠，不能访问用户空间，也不能调用调度程序。” -- LDD3。

Jermaine answers the rest of your question.

Jermaine 回答了您的其余问题。

[Update] In addition, I'd like to point out that one can define simple and elegant macros that help print debug info as and when required. Over the years, I've put these macros and convenience routines into a header file; you can check it out and download it here: "A Header of Convenience".

[更新] 另外，我想指出的是，可以定义简单而优雅的宏来帮助在需要时打印调试信息。多年来，我已将这些宏和便利例程放入头文件中；您可以在此处查看并下载：“A Header of Convenience”。

There are macros / functions to:

有宏/函数可以：

• make debug prints along with funcname / line# info (via the usual printk() or trace_printk()) and only if DEBUG mode is On
  • dump the kernel-mode stack
  • print the current context (process or interrupt along with flags in the form that ftraceuses)
  • a simple assert() macro (!)
  • a cpu-intensive DELAY_LOOP (useful for test rigs that must spin on the processor)
  • an equivalent to usermode sleep functionality
  • a function to calculate the time delta given two timestamps (timeval structs)
  • convert decimal to binary, and
  • a few more.

• 使调试打印与 funcname / line# info（通过通常的 printk() 或 trace_printk()）一起并且仅当 DEBUG 模式为 On
  • 转储内核模式堆栈
  • 打印当前上下文（进程或中断以及ftrace使用的形式的标志）
  • 一个简单的 assert() 宏 (!)
  • cpu 密集型 DELAY_LOOP（对于必须在处理器上旋转的测试台很有用）
  • 相当于用户模式睡眠功能
  • 一个函数来计算给定两个时间戳的时间增量（timeval 结构）
  • 将十进制转换为二进制，以及
  • 还有几个。

Whew :-)

哇:-)

回答by srd

I agree with the accepted answer and Kaiwan's answer, but they did not mention ksoftirqd. If the CPU is under heavy load of softirqs and/or tasklets, it schedules its ksfotirqd thread which process the raised softirqs and tasklets in process context.

我同意接受的答案和 Kaiwan 的答案，但他们没有提到 ksoftirqd。如果 CPU 处于软中断和/或小任务的重负载下，它会调度其 ksfotirqd 线程，该线程在进程上下文中处理引发的软中断和小任务。

So I guess the answer to the OP's question would be: softirqs can run in either interrupt or process contexts.

所以我想 OP 问题的答案是：软中断可以在中断或进程上下文中运行。