В каком контексте находятся softirq и тасклет?

Я знаю, что есть контекст процесса и контекст прерывания, но я не понимаю при выполнении softirq или тасклета, в каком контексте он выполняется.

Я видел, как некоторые люди используют термин «контекст нижней половины», если есть такой термин, какая разница по сравнению с другими.

Еще один вопрос к softirq и тасклету: почему сон не разрешен во время выполнения??

Может ли кто-нибудь помочь мне определить эти вопросы, спасибо!


linux linux-kernel interrupt softirq
person kai    schedule 21.08.2011    source источник

Ответы (3)


arrow_upward
18
arrow_downward

Программное прерывание и тасклет являются своего рода механизмом нижней половины. Сон не разрешен, потому что они выполняются в контексте прерывания, а не в контексте процесса. Если сон разрешен, то Linux не может запланировать их и, наконец, вызовет панику ядра с ошибкой dequeue_task. Контекст прерывания даже не имеет структуры данных, описывающей информацию о регистре, поэтому Linux никогда не может запланировать их выполнение. Если он спроектирован с такой структурой и может быть запланирован, это повлияет на производительность процесса обработки прерывания.

person Community    schedule 21.08.2011

arrow_upward
13
arrow_downward

@kai: ваш qs reg, в каком контексте выполняются нижние половины?

Технически do softirq запускается в контексте прерывания — контексте «softirq»; просто это не контекст «жесткого прерывания» (который является контекстом, когда происходит аппаратное прерывание).

Итак, в обработчике softirq, с точки зрения макросов «поиска», Linux предоставляет:

in_interrupt: да | in_irq: нет | in_softirq: да | in_serving_softirq: да

Но имейте в виду (осторожно!!! :): «все ограничения, которые применяются к обработчикам прерываний, также применяются к нижним половинам. Таким образом, нижние половины не могут спать, не могут получить доступ к пользовательскому пространству и не могут вызывать планировщик». -- ЛДД3.

Джермейн отвечает на остальную часть вашего вопроса.

[Обновление] Кроме того, я хотел бы отметить, что можно определить простые и элегантные макросы, которые помогают печатать отладочную информацию по мере необходимости. На протяжении многих лет я помещал эти макросы и удобные подпрограммы в заголовочный файл; вы можете ознакомиться с ним и загрузить его здесь: "Заголовок Удобство".

Есть макросы/функции для:

  • 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
    • распечатать текущий контекст (обработать или прервать вместе с флагами в форме, которую использует ftrace)< /сильный>
    • простой макрос assert() (!)
    • DELAY_LOOP с интенсивным использованием процессора (полезно для тестовых установок, которые должны вращаться на процессоре)
    • эквивалент функции сна в пользовательском режиме
    • функция для вычисления дельты времени с учетом двух меток времени (структуры timeval)
    • преобразовать десятичное число в двоичное и
    • еще несколько.

Уф :-)

person kaiwan    schedule 25.11.2011
comment
Мы также должны понимать, что примерно с версии 2.6.30 Томас Глейкснер (и другие) активно переводили традиционную модель обработки прерываний на многопоточную модель прерывания PREEMPT_RT. Итак, да, в этой модели традиционное «жесткое прерывание» теперь выполняется через поток ядра, то есть в контексте процесса! Сумасшедший ха. До тех пор, пока вы не поймете, что это сделано намеренно: чтобы поддерживать обработчики прерываний с приоритетом и иметь возможность иметь пути кода прерывания, вытесняемые потоками пользовательского режима «в реальном времени»! Ссылка: elinux.org/images/e/ef/InterruptThreads-Slides_Anderson.pdf< /а>‎ - person kaiwan; 11.01.2014

arrow_upward
8
arrow_downward

Я согласен с принятым ответом и ответом Кайвана, но они не упомянули ksoftirqd. Если ЦП сильно загружен отложенными прерываниями и/или тасклетами, он планирует свой поток ksfotirqd, который обрабатывает инициированные отложенные прерывания и тасклеты в контексте процесса.

Поэтому я предполагаю, что ответ на вопрос OP будет таким: softirqs может работать как в контексте прерывания, так и в контексте процесса.

person srd    schedule 17.10.2014
comment
Привет srd, это именно то, что беспокоило меня! Я читал в Linux Kernel Development [Robert Love], что отложенные прерывания и тасклеты запускаются в контексте прерывания. В книге также упоминается ksoftirqd, который является потоком ядра (и, следовательно, выполняется в контексте процесса). Как вы знаете, этот поток используется для каждого процессора для запуска отложенных прерываний/тасклетов, когда по какой-то причине (например, из-за большой нагрузки на сетевую карту) вызывается много отложенных прерываний/тасклетов. Но как поток (контекст процесса) запускает softirq/tasklet, который предназначен для работы только в контексте прерывания?! Я все еще не понимаю. - person Mohammad Ali Asgar; 20.10.2014
comment
Привет @MohammadAliAsgar! Я читаю ту же книгу (3-е издание), и насколько я понимаю: при вызове do_softirq() будет выполнено действие «softirq»; эта функция может быть вызвана либо из контекста прерывания, либо из обратного пути обработчика прерывания (hardirq), либо из контекста процесса (ksoftirqd поток ядра или другой код, например, сетевая подсистема). Вот как код может работать в любом контексте. И поскольку он может работать в контексте прерывания, он не должен спать, потому что планировщик не сможет перепланировать его. Возьмите это с недоверием, но надеюсь, что это поможет - person Catalin; 21.12.2020