cpu softirq time что это

Довольно интересно, что tasklet можно активировать и деактивировать, причем рекурсивно. За это отвечают следующие функции:

Если tasklet деактивирован, его по-прежнему можно добавить в очередь на планирование, но исполняться на процессоре он не будет до тех пор, пока не будет вновь активирован. Причем, если tasklet был деактивирован несколько раз, то он должен быть ровно столько же раз активирован, поле count в структуре как раз для этого.

А еще tasklet’ы можно убивать. Вот так:

Причем, убит он будет только после того, как tasklet исполнится, если он уже запланирован. Если вдруг tasklet планирует сам себя, то нужно перед вызовом этой функции не забыть запретить ему это делать — это на совести программиста.

Интереснее всего функции, которые играют роль планировщика:

Так как они практически одинаковые, то нет смысла приводить код обеих функций. Но вот на одну из них стоит взглянуть, чтобы разобраться поподробнее:

Обратите внимание на вызов функций tasklet_trylock() и tasklet_lock(). tasklet_trylock() выставляет tasklet’у состояние TASKLET_STATE_RUN и тем самым блокирует tasklet, что предотвращает исполнение одного и того же tasklet’а на разных CPU.

Эти функции-планировщики, по сути, реализуют кооперативную многозадачность, которую я подробно рассматривала в своей статье. Функции регистрируются как обработчики softirq, который инициируется при планировании tasklet’ов.

Реализацию всех вышеописанных функций можно посмотреть в файлах include/linux/interrupt.h и kernel/softirq.c.

Продолжение следует

В следующей части я расскажу о гораздо более мощном механизме — workqueue, который также часто используется для отложенной обработки прерываний.

Источник

Cpu softirq time что это

Узкие места сетевой подсистемы Linux. Тюнинг сети в Linux. Настройка производительности сети в модели NAPI и с прерываниями.

Создано 22.11.2016 11:53

Опубликовано 22.11.2016 11:53

Узкие места сетевой подсистемы Linux. Тюнинг сети в Linux. Настройка производительности сети в модели NAPI и с прерываниями.

Кольцевой буфер

Кольцевые буферы, совместно используются драйвером устройства и сетевой картой. TX – есть передача данных, а RX – получение данных в кольцевом буфере. Как следует из названия, переполнение буфера просто перезаписывает существующие данные. Есть два способа переместить данные от сетевой карты до ядра: аппаратные прерывания и программные прерывания, названные SoftIRQs.

Кольцевой буфер RX используется, чтобы сохранить входящие пакеты, пока они не могут быть обработаны драйвером устройства. Драйвер устройства опустошает буфер RX, обычно через SoftIRQs, который помещает входящие пакеты в структуру данных ядра, названную sk_buff или «skb», чтобы начать свой путь через ядро и до приложения, которому принадлежит соответствующий сокет. Кольцевой буфер TX используется для хранения исходящих пакетов, которые предназначенные для отправки по проводам.

Эти кольцевые буферы находятся у основания стека и являются критическим моментом, в который может произойти удаление (drop) пакетов, что негативно влияет на производительность сети.

Прерывания и обработчики прерываний

Прерывания от аппаратных средств известны как прерывания «top-half».

Жесткие прерывания можно увидеть в /proc/interrupts, где у каждой очереди есть vector прерывания в 1-м столбце. Каждой очереди RX и TX присвоен уникальный vector, который сообщает обработчику прерываний, относительно какого NIC/queue пришло прерывание. Столбцы представляют количество входящих прерываний:

#egrep «CPU0|eth1» /proc/interrupts

CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7

45: 28324194 0 0 0 0 0 0 0 PCI-MSI-edge eth1

SoftIRQs

Иизвестны как прерывания «bottom-half», запросы программного прерывания (SoftIRQs), являются подпрограммами ядра, которые планируется запустить в то время, когда другие задачи не должны быть прерваны. Цель SoftIRQ состоит в извлечении данных из кольцевых буферов. Эти подпрограммы, выполненные в форме процессов ksoftirqd/cpu-number и, вызывают специфичные для драйвера функции кода.

После перемещения данных от драйвера к ядру, трафик двигатется вверх к сокету приложения.

SoftIRQs можно контролировать следующим образом. Каждый столбец есть ЦП:

NAPI Polling

Поиск узкого места

Для примера вывод статистики ethtool:

Существуют различные инструменты, доступные для поиска проблемной области. Следует исследовать:

• Уровень встроенного ПО адаптера

• Уровень драйвера адаптера

• Ядро Linux, IRQs или SoftIRQs

— Проверяем /proc/interrupts и /proc/net/softnet_stat

• Уровни протокола IP, TCP, UDP

Вот некоторые типичные примеры узких мест:

# egrep “CPU0|eth2” /proc/interrupts

CPU0 CPU1 CPU2 CPU3 CPU4 CPU5

105: 1430000 0 0 0 0 0 IR-PCI-MSI-edge eth2-rx-0

106: 1200000 0 0 0 0 0 IR-PCI-MSI-edge eth2-rx-1

107: 1399999 0 0 0 0 0 IR-PCI-MSI-edge eth2-rx-2

108: 1350000 0 0 0 0 0 IR-PCI-MSI-edge eth2-rx-3

109: 80000 0 0 0 0 0 IR-PCI-MSI-edge eth2-tx

0073d76b 00000000 000049ae 00000000 00000000 00000000 00000000 00000000 00000000 00000000

000000d2 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0000015c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Настройка производительности

SoftIRQ

Если выполнение программных прерываний не выполняются достаточно долго, то темп роста входящих данных может превысить возможность ядра опустошить буфер. В результате буферы NIC переполнятся, и трафик будет потерян. Иногда, необходимо увеличить длительность работы SoftIRQs (программных прерываний) с CPU. За это отвечает netdev_budget. Значение по умолчанию 300. Параметр заставит процесс SoftIRQ обработать 300 пакетов от NIC перед тем как отпустить CPU:

Это значение может быть удвоено, если 3-й столбец в /proc/net/softnet_stat увеличивается, что указывает, на то, что SoftIRQ не получил достаточно процессорного времени. Маленькие инкременты нормальны и не требуют настройки.

0073d76b 00000000 000049ae 00000000 00000000 00000000 00000000 00000000 00000000 00000000

000000d2 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0000015c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0000002a 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

IRQ Balance

Прерывания также можно раскидать по ядрам вручную.

#CPU0
echo 1 > /proc/irq/57/smp_affinity
echo 1 > /proc/irq/66/smp_affinity

#CPU1
echo 2 > /proc/irq/58/smp_affinity
echo 2 > /proc/irq/67/smp_affinity

#CPU2
echo 4 > /proc/irq/59/smp_affinity
echo 4 > /proc/irq/68/smp_affinity

#CPU3
echo 8 > /proc/irq/60/smp_affinity
echo 8 > /proc/irq/69/smp_affinity

Для того, чтобы при старте системы прерывания сами настраивались, можно сделать скрипт и настроить его запуск /etc/rc.d/rc.local.

Ethernet flow control

Однако, важно понимать, что этот уровень контроля потока только между коммутатором и адаптером. Если пакеты отброшены, более высокие уровни, такие как TCP или приложение в случае UDP и/или многоадресно переданы, должен инициировать восстановление.

Важно! Фреймы паузы и flow control (управление потоком) должны быть включены и на NIC и на порте коммутатора.

Pause parameters for eth3:

Pause parameters for eth3:

Interrupt Coalescence (отложенные прерывания)

Отложенные прерывания рассказывают нам о количестве трафика, который будет получать сетевой интерфейс, или времи, которое проходит после приема трафика, перед выдачей жесткого прерывания. Слишком ранние прерывания или слишком частые приводят к снижению производительности системы, так как ядро останавливается (или «перебивает») запущенное задание для обработки запроса прерывания от аппаратного обеспечения. Слишком поздее прерывание может привести к тому, что пакеты достаточно долго не будут обработаны ядром с сетевой карты. Большие объемы трафика могут переписать предыдущие пакеты трафика, т.е. потеря пакетов.

Coalesce parameters for eth3:

Adaptive RX: on TX: off

Следующая команда выключает адаптивный IC, и говорит адаптеру о прерывании ядра

сразу после приема любого трафика:

Очередь адаптера (The Adapter Queue)

0073d76b 00000000 000049ae 00000000 00000000 00000000 00000000 00000000 00000000 00000000

000000d2 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0000015c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

0000002a 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

В текущем выводе netdev_max_backlog не нуждается в тюнинге, т.к. очередь не переполняется и нет потерь соответственно. Если же наблюдаются приащения в второй колонке, тогде увеличиваем значение очереди и снова смотрим в этот файл. Если увеличения этого значения мы видим что скорость приращений в втором столбце уменьшается то можно еще увеличить значение backlog. Повторяем этот процесс пока перестанет расти цифры в столбце 2.

Backlog изменить можно такой командой:

Adapter RX and TX Buffer

Буфер адаптера по умолчанию обычно установлен в меньшем размере, чем максимальный. Часто, увеличить размер буфера приема RX вполне достаточно, чтобы предотвратить потери пакетов, так как это может приводит к тому, что у ядра будет немного больше времени, чтобы опустошить буфер. В результате, это может предотвратить возможные потери пакетов.

Буферы можно посмотреть так:

Ring parameters for eth3:

Current hardware settings:

Тут видим что кольцевой буфер RX входящих пакетов равен 1024 дескрипторам в оперативной памяти, и можно увеличить до 8192.

Очередь передачи (Adapter Transmit Queue Length)

Увеличить длину очереди можно так:

TCP Window Scaling (масштабирование окна TCP)

Размер TCP окна (TCP Window Size) – количество октетов (начиная с номера подтверждения), которое принимающая сторона готова принять в настоящий момент без подтверждения. На стадии установления соединения рабочая станция и сервер обмениваются значениями максимального размера TCP окна (TCP Window Size), которые присутствуют в пакете. Например, если размер окна получателя равен 16384 байта, то отправитель может отправить 16384 байта без остановки. Принимая во внимание, что максимальная длина сегмента (MSS) может быть 1460 байт, то отправитель сможет передать данный объем в 12 фреймах, и затем будет ждать подтверждение доставки от получателя и информации по обновлению размера окна. Если процесс прошел без ошибок, то размер окна может быть увеличен. Таким образом, реализуется размер скользящего окна в стеке протокола TCP. В современных версиях операционных систем можно увеличить размер окна TCP Window Size и включить динамическое изменение окна в зависимости от состояния канала связи. Динамическое увеличение и уменьшение размера окна является непрерывным процессом в TCP и определяет оптимальный размер окна для каждого сеанса. В очень эффективных сетях размеры окна могут стать очень большими, потому что данные не теряются.

Масштабирование Окна TCP включено по умолчанию:

TCP буфер

После того, как сетевой трафик обрабатывается от сетевого адаптера, предпринимается попытка приема трафика непосредственно в приложение. Если это не представляется возможным, данные ставятся в очередь на буфер сокета приложения. Есть 3 структуры очереди в сокете:

sk_rmem_alloc – очередь получения

sk_wmem_alloc – очередь передачи

Существует также sk_rcvbuf переменная, которая является пределом, измеренный в байтах, что сокет может получить. В этом случае sk_rcvbuf = 125336.

Из приведенного выше вывода можно вычислить, что очередь получения почти полна. Когда sk_rmem_alloc > sk_rcvbuf то буфер начинает рушится, т.е. наблюдаются потери пакетов. Выполните следующую команду, чтобы определить, происодит это или нет:

17671 packets pruned from receive queue because of socket buffer overrun

18671 packets pruned from receive queue because of socket buffer overrun

Если счетчик обрезки пакетов растет, то требуется тюнинг.

tcp_rmem: У настраиваемой памяти сокета есть три значения, описывающих минимальное, значение по умолчанию и максимальное значения в байтах. Чтобы просмотреть эти настройки и увеличить:

4096 87380 4194304

# sysctl net.core.rmem_max 4194304

После изменения максимального размера, требуется перезапуск приложения.

Источник

Русские Блоги

Пятая подсистема прерывания (прерывания) Linux: программное прерывание (softIRQ) (передача)

1. Структура данных программного прерывания

1.1 struct softirq_action

Ядро использует структуру softirq_action для управления регистрацией и активацией программных прерываний, и ее определение выглядит следующим образом:

Очень просто, есть только один указатель на функцию для обратных вызовов. Ресурсы программных прерываний ограничены. В настоящее время ядро ​​реализует только 10 типов программных прерываний. Это:

Разработчики ядра не рекомендуют увеличивать количество программных прерываний без авторизации.Если нужны новые программные прерывания, попробуйте реализовать их в виде тасклета на основе программных прерываний. В соответствии с перечисленными выше значениями ядро ​​определяет массив структуры softirq_action, и каждое мягкое прерывание соответствует одному элементу в массиве:

1.2 irq_cpustat_t

Несколько программных прерываний могут выполняться на нескольких процессорах одновременно, даже мягкие прерывания одного и того же типа могут выполняться на нескольких процессорах одновременно. Ядро управляет ожидающей переменной мягкого прерывания (ожидающей) для каждого процессора, которой является irq_cpustat_t:

Каждый бит в поле __softirq_pending соответствует определенному мягкому прерыванию, и установлен определенный бит, указывающий на наличие соответствующего мягкого прерывания, ожидающего обработки.

1.3 Демон мягкого прерывания ksoftirqd

На этапе горячей замены процессора ядро ​​создает процесс демона ksoftirqd для выполнения программных прерываний для каждого процессора и определяет переменную per_cpu для сохранения указателя структуры task_struct каждого демона:
DEFINE_PER_CPU(struct task_struct *, ksoftirqd);
В большинстве случаев мягкое прерывание будет выполняться на этапе irq_exit, а мягкое прерывание, которое не было обработано на этапе irq_exit, может быть выполнено в демоне.

2. Запуск мягкого прерывания

Чтобы вызвать мягкое прерывание, просто вызовите raise_softirq, его реализация очень проста, сначала закройте прерывание локального процессора, а затем вызовите: raise_softirq_irqoff

Сначала установите бит флага отложенного мягкого прерывания (irq_stat [NR_CPUS]) процессора через __raise_softirq_irqoff, а затем используйте in_interrupt, чтобы определить, находится ли он в настоящее время в контексте прерывания или мягкое прерывание отключено. Если нет, разбудите демон мягкого прерывания. Функция обратного вызова, которая выполняет мягкое прерывание в демоне. В противном случае ничего не делайте, и мягкое прерывание будет выполнено во время фазы выхода из прерывания.

3. Выполнение мягкого прерывания

Исходя из вышеизложенного, выполнение мягких прерываний может выполняться либо в процессе демона, либо в фазе выхода прерывания. Фактически, мягкие прерывания чаще выполняются во время фазы выхода из прерывания (irq_exit), чтобы добиться более быстрого ответа. Добавлен механизм демона, но его беспокоит только то, что, когда большое количество мягких прерываний ожидает выполнения, ядро ​​будет оставаться слишком долго. Контекст прерывания.

3.1 Выполнить в irq_exit

Посмотрите на часть irq_exit:

Если прерывания вложены, in_interrupt () гарантирует, что invoke_interrupt будет вызываться только в фазе irq_exit самого внешнего прерывания.Конечно, local_softirq_pending также определит, есть ли у текущего процессора ожидающее мягкое прерывание. В конечном итоге код войдет в __do_softirq, а ядро ​​будет гарантировать, что при вызове __do_softirq прерывание локального процессора будет отключено и введите __do_softirq:

3.2 Выполнить в процессе ksoftirqd

Из обсуждения в предыдущих разделах мы видим, что мягкие прерывания также могут выполняться демоном ksoftirqd. Это произойдет в следующих двух ситуациях:

В конечном итоге демон вызовет __do_softirq для выполнения обратного вызова мягкого прерывания. Конкретный код находится в функции run_ksoftirqd. Ядро выполнит __do_softirq, когда приоритетное прерывание отключено. Конкретный процесс здесь не обсуждается.

4. tasklet

4.1 tasklet_struct

В конце функции инициализации softtirq_init мягкого прерывания ядро ​​регистрирует два мягких прерывания, TASKLET_SOFTIRQ и HI_SOFTIRQ:

Ядро использует tasklet_struct для представления тасклета, и его определение выглядит следующим образом:

Next используется для связывания тасклета того же процессора в связанный список, а состояние используется для обозначения текущего состояния тасклета. В настоящее время используются только два младших бита, которые указывают, что они готовы к планированию для выполнения и уже находятся на другом процессоре выполненный:

4.2 Инициализировать тасклет

4.3 Как использовать тасклет

Чтобы включить и отключить тасклет, используйте следующие функции:

Чтобы запланировать выполнение тасклета, используйте следующие функции:

Чтобы уничтожить тасклет, используйте следующую функцию:

4.4 Внутренний механизм выполнения тасклета

Ядро определяет структуру tasklet_head для каждого ЦП для управления планированием и выполнением тасклета на каждом ЦП:

Анализ выглядит следующим образом:

Проанализировав это, у меня есть вопрос: если после прочтения приведенного выше кода тасклет отключен с помощью tasklet_schedule до его выполнения, вызовет ли это бесконечные мягкие прерывания TASKLET_SOFTIRQ?
В ходе приведенного выше анализа мы должны отметить, что тасклет имеет следующие характеристики:

Источник

Русские Блоги

1 обзор

Когда процессор ARM это прерывание, процессор выполняет ненормальный переключатель режимов работы. В это время, прерывание отключается, и прерывание включаются после обработки.

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

Прерывать Bottom-half Механизм, в том числе softirq 、 tasklet 、 workqueue И прерывание резьбы упоминалось выше, в том числе tasklet Основываться на softirq Для достижения, это также предмет обсуждается в этой статье;

Во время обработки прерывания, вы можете чернила всех виды контекста обсуждения, понять различие между различными контекстами для помощи прерывания обработки, так что прийти к старой карте:

task_struct структурная thread_info.preempt_count Используется для записи текущей задачи context штат;

PREEMPT_BITS : Используется для записи количества запретов, запрещено захватить значение, добавьте 1, включить значение для уменьшения значения 1;

SOFTIRQ_BITS : Используется для синхронной обработки, добавления 1, когда нижняя половина выключается, и открывается нижняя половина;

HARDIRQ_BITS : Используется для указания в контексте аппаратного прерывания;

Прелюдия закончилась, идти прямо к теме.

2. softirq

2.1 инициализация

softirq Динамическое распределение не поддерживаются, Linux Kernel обеспечивает статическое распределение, а также основные структуры описаны ниже, которые могут быть понят, чем аппаратные прерывания:

Мягкое прерывание может выполняться параллельно на разных процессорах, только серийное исполнение на тот же процессор;

Каждое техническое обслуживание CPU irq_cpustat_t Государственная структура, когда мягкие потребности прерывания должны быть обработаны, структура __softirq_pending поле или 1UL ；

2.2 Анализ процесса

Регистрация 2.2.1 Soft Прерывание

Прерывание потока обработки в драйвере устройства request_irq/request_threaded_irq Интерфейс для регистрации прерывания обработки функций, и проходит через мягкие прерывания процесса обработки open_softirq Интерфейс для регистрации, потому что это слишком просто, я не могу помочь, но разместить код:

То есть, соответствующий дескриптор мягкого прерывания таблицы дескрипторов handler Точки указателя функции в соответствующей функции, так что обратный вызов включен мягкий.

Таким образом, проблема приходит, когда это мягкое прерывание функции обратного вызова?

2.2.2 Исполнение Мягкое Прерывание: Обработка прерываний

Первый взгляд на первом случае, используйте картинку отвечать на вопросы:

существовать __handle_domain_irq В функции, irq_enter с участием irq_exit Он используется для идентификации и отпуска аппаратного прерывания обработки контекста, это от preempt_count_add/preempt_count_sub Для работы HARDIRQ_OFFSET Можно видеть, что это также соответствует описанию контекста выше;

invoke_softirq В функции, обработка классификации производятся в соответствии с обработкой прерываний, и если прерывание было исполнено, оно было исполнено, и необходимо, чтобы передать параметры при запуске. threadirqs ), Затем перейти непосредственно wakeup_softirqd Просыпайтесь нить ядра для выполнения, в противном случае звонит __do_softirq Функция ручки;

Логика в приведенном выше рисунке можно видеть, что окончательная обработка ядра помещается __do_softirq Завершенный в функции:

local_softirq_pending Функция используется для чтения __softirq_pending Поля, можно определить, есть ли запрос обработки мягкого прерывания, чем регистр состояния, чем драйвер устройства;

Мягкое прерывание будет закрыто Bottom-half После того, как обработка законченная;

Когда мягкое прерывание обрабатываются, будет открыто локальное прерывание, и локальное прерывание отключается после обработки. Это место соответствует указанному выше Top-half с участием Bottom-half Механизм, в Bottom-half При обработке, он будет включен, поэтому он будет продолжать реагировать на другие прерывания, что означает, что другие прерывания могут также прерывания тока Bottom-half иметь дело с;

__do_softirq Так как она может быть вызвана во время обработки прерываний, оно может также ksoftirqd Средний платеж, то softirq Производительность может иметь два контекста, плагин карты:

Вдумаемся последний вопрос: Когда аппаратное прерывание срабатывает, то электрический сигнал аппаратного устройства Что такое триггер мягких прерываний.? Ответ передается raise_softirq интерфейс:

Может вызываться во время обработки прерываний raise_softirq Для того, чтобы сделать запрос мягкого прерывания обработки, фактическая обработка также упоминалось выше. irq_exit После выхода из аппаратного прерывания контекста;

raise_softirq_irqoff В функции, в конце концов называют or_softirq_pending Эта функция будет читать локальный процессор irq_stat середина __softirq_pending Поле, а затем установить соответствующую мягкую подпись, что указывает на запрос на обработку мягкого прерывания;

raise_softirq_irqoff В функции, она будет определять контекст среду текущего запроса. Если это не в контексте прерывания, вы можете обрабатывать нить ядра пути пробуждения потока ядра. Если он обрабатывается в контексте прерывания, не будет казнены;

Скажем больше, в мягком прерывания на протяжении всего процесса, часто видят in_interrupt() Условное суждение, это обеспечивает мягкое прерывание в серийном исполнении на процессоре, чтобы избежать вложенных;

2.2.3 Soft Interrupt III: Снизу Half Enable

Второй тип мягкого прерывания точки выполнения, в Bottom-half Если эта функция включена, то, как правило, используется для параллельной обработки, и контекст пространства процесса называется:

Когда мы говорим параллелизм, мы говорили Bottom-half Ситуацию с процессом ресурсов между процессами, если есть критический ресурс между мягкими прерываниями и процессами (мягким прерыванием контекста приоритетом, чем контекст процесса), то его можно назвать в контексте процесса. local_bh_disable/local_bh_enable Приходите к критически важным ресурсам;

Функции на левой части рисунка используются для открытой Bottom-half Интерфейс можно увидеть spin_lock_bh/read_lock_bh/write_lock_bh Вариант форма параллельного интерфейса обработки называется;

__local_bh_enable_ip В функции, в первую очередь определить, является ли прерывание закрытым, когда интерфейс называется, если интерфейс BH выключен, это будет сигнал тревоги;

Почему это дало? Bottom-half Вы хотите, чтобы выполнить мягкое прерывание? При обработке параллелизма, возможно, он уже поставил Bottom-half После завершения работы, если прерывание нарушается, мягкое прерывание не будет обрабатываться, открытым в контексте процесса. Bottom-half В это время, он будет проверять, есть ли мягкие прерывания обработки запроса;

3. tasklet

Как видно из приведенного выше анализа. tasklet Является ли тип мягкого прерывания, то есть разница между этими двумя? Давайте поговорим об этом первым:

Мягкое прерывание ядро ​​типа статическое распределение, нет динамического распределения, tasklet Поддержка динамического и статического распределения, то есть, водитель может быть более удобным для расширения;

Мягкое прерывание может работать параллельно на нескольких процессорах, так что вы должны рассмотреть вопрос о повторном входе и tasklet Буду связанно с процессором, после запуска, а затем разлагается, нет необходимости повторного ввода, конечно, его производительность не будет падать;

Структура данных 3.1

DEFINE_PER_CPU(struct tasklet_head, tasklet_vec) Назначают каждый процессор tasklet_head Структура, эта структура используется для поддержания struct tasklet_struct Таблица Link, вы должны поместить его на CPU tasklet В связанном списке структуры, две связанные списки сохраняются для каждого процессора в ядре. tasklet_vec с участием tasklet_vec_hi Корреспондент две разные приоритеты, то эта статья tasklet_vec Возьмем пример;

struct tasklet_struct для tasklet Абстракция, несколько ключевых полей показаны на рисунке, через next Для связи в цепи, проходят state Поля, чтобы определить различный статус для обеспечения последовательного выполнения на процессоре, func Указатель Функция называется task_init() Инициализация, когда интерфейс выполняется, и выполняется, когда мягкое прерывание срабатывает, наконец;

3.2 Анализ процесса

tasklet По существу, это мягкое прерывание, поэтому его вызывающий процесс согласуется с мягким процессом прерывания рассмотренном выше;

Функция процесса, выполняемая с помощью мягкого прерывания является tasklet_action Это softirq_init Передайте функции open_softirq Функция зарегистрирована;

tasklet_action Функция, первый поставил процессор tasklet_vec Связанный список перешел к временному связному списку list В середине, то этот list Вызов обработки обхода, если условия выполнения будут выполнены, вызов t->func() Выполнить и continue Перейти на следующий узел. Если вы не соответствуете условиям реализации, по-прежнему tasklet Добавить на оригинал tasklet_vec В, и вызвать мягкое прерывание снова;

Источник