Ksoftirqd linux что это



Ksoftirqd linux что это

Обработка отложенных прерываний ( softirq ) и, соответственно, тасклетов осуществляется с помощью набора потоков пространства ядра (по одному потоку на каждый процессор). Потоки пространства ядра помогают обрабатывать отложенные прерывания, когда система перегружена большим количеством отложенных прерываний.

$ ps -ALf | head -n12

Для каждого процессора существует свой поток. Каждый поток имеет имя в виде ksoftirqd/n , где п — номер процессора. Например, в двухпроцессорной системе будут запущены два потока с именами ksoftirqd/0 и ksoftirqd/1 . To, что на каждом процессоре выполняется свой поток, гарантирует, что если в системе есть свободный процессор, то он всегда будет в состоянии выполнять отложенные прерывания. После того как потоки запущены, они выполняют замкнутый цикл.

Очереди отложенных действий (workqueue)

Очереди отложенных действий ( workqueue ) — это еще один, но совершенно другой, способ реализации отложенных операций. Очереди отложенных действий позволяют откладывать некоторые операции для последующего выполнения потоком пространства ядра (эти потоки ядра называют рабочими потоками — worker threads ) — отложенные действия всегда выполняются в контексте процесса. Поэтому код, выполнение которого отложено с помощью постановки в очередь отложенных действий, получает все преимущества, которыми обладает код, выполняющийся в контексте процесса, главное из которых — это возможность переходить в блокированные состояния. Рабочие потоки, которые выполняются по умолчанию, называются events/n , где n — номер процессора, для 2-х процессоров это будут events/0 и events/1 :

$ ps -ALf | head -n12

Когда какие-либо действия ставятся в очередь, поток ядра возвращается к выполнению и выполняет эти действия. Когда в очереди не остается работы, которую нужно выполнять, поток снова возвращается в состояние ожидания. Каждое действие представлено с помощью struct work_struct (определяется в файле
— очень меняется от версии к версии ядра!):

Для создания статической структуры действия на этапе компиляции необходимо использовать макрос:

Это выражение создает struct work_struct с именем name , с функцией-обработчиком func() и аргументом функции-обработчика data . Динамически отложенное действие создается с помощью указателя на ранее созданную структуру, используя следующий макрос:

Функция-обработчика имеет тот же прототип, что и для отложенных прерываний и тасклетов, поэтому в примерах будет использоваться та же функция ( xxx_analyze() ).

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

При инициализации модуля создаём отложенное действие:

Или то же самое может быть выполнено статически

Самая интересная работа начинается когда нужно запланировать отложенное действие; при использовании для этого рабочего потока ядра по умолчанию ( events/n ) это делается функциями :

— schedule_work( struct work_struct *work ); — действие планируется на выполнение немедленно и будет выполнено, как только рабочий поток events, работающий на данном процессоре, перейдет в состояние выполнения.

— schedule_delayed_work( struct delayed_work *work, unsigned long delay ); — в этом случае запланированное действие не будет выполнено, пока не пройдет хотя бы заданное в параметре delay количество импульсов системного таймера.

В обработчике прерывания это выглядит так:

Очень часто бывает необходимо ждать пока очередь отложенных действий очистится (отложенные действия завершатся), это обеспечивает функция:

Для отмены незавершённых отложенных действий с задержками используется функция:

Но мы не обязательно должны рассчитывать на общую очереди (потоки ядра events ) для выполнения отложенных действий — мы можем создать под эти цели собственные очереди (вместе с обслуживающим потоком). Создание обеспечивается макросами вида:

Планирование на выполнение в этом случае осуществляют функции:

Они аналогичны рассмотренным выше schedule_*() , но работают с созданной очередью, указанной 1-м параметром. С вновь созданными потоками предыдущий пример может выглядеть так:

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

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

Источник

Ksoftirqd linux что это

Published on: April 29, 2019 by Aaden Dev

Operating System manages and controls I/O operations and I/O devices. Let’s have a quick overview of different ways of interacting with I/O devices, before we go through what a ksoftirqd does.

Interrupts – The CPU issues commands to the I/O module then proceeds with its normal work until interrupted by I/O device on completion of its work.

DMA – Direct Memory Access (DMA) means CPU grants I/O module, the authority to read from or write to memory without involvement.

Polling – OS simply checks from time to time if a device has completed a request.

There is DMA + Interrupts as well as DMA + polling as well.

Now let’s consider the interrupts way of interacting with the I/O. Interrupts from the hardware are known as “top-half” interrupts. Interrupts are best explained with network traffic.

When a NIC receives incoming data, it copies the data into kernel buffers using DMA. The NIC notifies the kernel of this data by raising a hard interrupt. These interrupts are processed by interrupt handlers which do minimal work, as they have already interrupted another task and cannot be interrupted themselves.

Hard interrupts can be expensive in terms of CPU usage, especially when holding kernel locks. The hard interrupt handler then leaves the majority of packet reception to a software interrupt, or SoftIRQ, a process which can be scheduled more fairly.

Hard interrupts can be seen in /proc/interrupts while soft interrupts can be seen at /proc/softirqs

The softirq system in the Linux kernel is a mechanism for executing code outside of the context of an interrupt handler implemented in a driver. This system is important because hardware interrupts may be disabled during all or part of the execution of an interrupt handler. When the interrupt handlers are processing the interrupts, they cannot be interrupted themselves. That is why we have the interrupt handlers doing the minimal work, of interruption, while the responsibility of actual receiving of network traffic is managed by software interrupts.

In some situations, IRQs come very very fast one after the other and the operating system cannot finish servicing one before another one arrives. One of the mechanisms of deferring the tasks is by implementing a queuing system, called ksoftirqd. ksoftirqd, is utilized when the machine is under heavy soft interrupt load.

If ksoftirqd is taking more than a certain percentage of CPU time, this indicates the machine is under heavy interrupt load and not eating CPU. If there is a bug in a driver or any other issue, you can see that one CPU is taking too much load while others are underutilized.

You can tweak the settings a bit, by defining which CPU picks up a certain
interrupt. You do this by changing the contents of /proc/irq/$interrupt_number/smp_affinity. You can get a list of interrupts and their meaning by doing:

cat /proc/interrupts

The number in smp_affinity is a bitmap of CPUs, represented in hex code. The rightmost bit is the least significant. For instance, if the system has 8 cores and you only wanted to use cores 0, 1 and 3, you should set the smp_affinity to

1a:

cpu_7 cpu_6 cpu_5 cpu_4 cpu_3 cpu_2 cpu_1 cpu_0
0 0 0 0 1 0 1 1 = 00001011 = 0B (in hex)

For eg: if you want to set up any of the CPU to be able to pick up interrupt 38 (eth0 in my 8-core system) with:

sudo echo ff > /proc/irq/38/smp_affinity

Источник

Демон ksoftirqd

Обработка отложенных прерываний (softirq) и, соответственно, тасклетов может осуществляться с помощью набора потоков пространства ядра (по одному потоку на каждый процессор). Потоки пространства ядра помогают обрабатывать отложенные прерывания, когда система перегружена большим количеством отложенных прерываний.

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

Первое решение — это немедленная обработка всех отложенных прерываний, как только они приходят, а также обработка всех ожидающих отложенных прерываний перед возвратом из обработчика. Это решение гарантирует, что все отложенные прерывания будут обрабатываться немедленно и в то же время, что более важно, что все вновь активизированные отложенные прерывания также будут немедленно обработаны. Проблема возникает в системах, которые работают при большой загрузке и в которых возникает большое количество отложенных прерываний, которые постоянно сами себя активизируют. Ядро может постоянно обслуживать отложенные прерывания без возможности выполнять что-либо еще. Заданиями пространства пользователя пренебрегают, а выполняются только лишь обработчики прерываний и отложенные прерывания, в результате пользователи системы начинают нервничать. Подобный подход может хорошо работать, если система не находится под очень большой нагрузкой. Если же система испытывает хотя бы умеренную нагрузку, вызванную обработкой прерываний, то такое решение не применимо. Пространство пользователя не должно продолжительно страдать из-за нехватки процессорного времени.

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

Необходим какой-нибудь компромисс. Решение, которое реализовано в ядре, — не обрабатывать немедленно вновь активизированные отложенные прерывания. Вместо этого, если сильно возрастает количество отложенных прерываний, ядро возвращает к выполнению (wake up) семейство потоков пространства ядра, чтобы они справились с нагрузкой. Данные потоки ядра работают с самым минимально возможным приоритетом (значение параметра nice равно 19). Это гарантирует, что они не будут выполняться вместо чего-то более важного. Но они в конце концов тоже когда-нибудь обязательно выполняются. Это предотвращает ситуацию нехватки процессорных ресурсов для пользовательских программ. С другой стороны, это также гарантирует, что даже в случае большого количества отложенных прерываний они все в конце концов будут выполнены. И наконец, такое решение гарантирует, что в случае незагруженной системы отложенные прерывания также обрабатываются достаточно быстро (потому что соответствующие потоки пространства ядра будут запланированы на выполнение немедленно).

Для каждого процессора существует свой поток. Каждый поток имеет имя в виде ksoftirqd/n, где n — номер процессора. Так в двухпроцессорной системе будут запущены два потока с именами ksoftiqd/0 и ksoftirqd/1. To, что на каждом процессоре выполняется свой поток, гарантирует, что если в системе есть свободный процессор, то он всегда будет в состоянии выполнять отложенные прерывания. После того как потоки запущены, они выполняют замкнутый цикл, похожий на следующий.

Если есть отложенные прерывания, ожидающие на обработку (что определяет вызов функции softirq_pending()), то поток ядра ksoftirqd вызывает функцию do_softirq(), которая эти прерывания обрабатывает. Заметим, что это делается периодически, чтобы обработать также вновь активизированные отложенные прерывания. После каждой итерации при необходимости вызывается функция schedule(), чтобы дать возможность выполняться более важным процессам. После того как вся обработка выполнена, поток ядра устанавливает свое состояние в значение TASK_INTERRUPTIBLE и активизирует планировщик для выбора нового готового к выполнению процесса.

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

Читайте также

Демон pdflush

Демон pdflush Измененные (dirty, «грязные») страницы памяти когда-нибудь должны быть записаны на диск. Обратная запись страниц памяти выполняется в следующих двух случаях.• Когда объем свободной памяти становится меньше определенного порога, ядро должно записать измененные

Демон

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

13.2. Демон syslogd

13.2. Демон syslogd Системы Unix обычно запускают демон syslogd в одном из сценариев инициализации системы, и он функционирует, пока система работает. Реализации syslogd, происходящие от Беркли, выполняют при запуске следующие действия:1. Считывается файл конфигурации, обычно /etc/syslog.conf,

13.5. Демон inetd

13.5. Демон inetd В типичной системе Unix может существовать много серверов, ожидающих запроса клиента. Примерами являются FTP, Telnet, Rlogin, TFTP и т.д. В системах, предшествующих 4.3BSD, каждая из этих служб имела связанный с ней процесс. Этот процесс запускался во время загрузки из файла

28.7. Демон сообщений ICMP

28.7. Демон сообщений ICMP Получение асинхронных ошибок ICMP на сокет UDP всегда было и продолжает оставаться проблемой. Ядро получает сообщения об ошибках ICMP, но они редко доставляются приложениям, которым необходимо о них знать. Мы видели, что для получения этих ошибок в API

Демон icmpd

Демон icmpd Начинаем описание нашего демона icmpd с заголовочного файла icmpd.h, приведенного в листинге 28.23.Листинг 28.23. Заголовочный файл icmpd.h для демона icmpd//icmpd/icmpd.h 1 #include «unpicmpd.h» 2 struct client < 3 int connfd; /* потоковый доменный сокет Unix к клиенту */ 4 int family; /* AF_INET или AF_INET6 */ 5 int lport; /*

5.4. Демон inetd/xinetd

5.4. Демон inetd/xinetd Для того чтобы сервер смог обрабатывать запросы клиентов, программа должна быть постоянно загружена и связана с определенным портом. В этом нет ничего сложного, но зачем постоянно держать программу в памяти, особенно если она слишком большая, а работает

5.8.5. Демон klogd

5.8.5. Демон klogd Демон klogd предназначен для перехвата и протоколирования сообщений ядра Linux (klogd расшифровывается как kernel-logging daemon). В своей работе вы можете использовать параметры демона, указанные в табл. 5.9.Параметры демона klogd Таблица 5.9 Параметр Описание -c n

9.4.2. Диспетчер расписаний — демон cron

9.4.2. Диспетчер расписаний — демон cron Этот демон запускается во время инициализации системы (сценарий /etc/init.d/crond), читает свои конфигурационные файлы и переходит в режим ожидания. Раз в минуту демон просыпается, проверяет дату последнего изменения конфигурационных файлов,

19.2.1. Демон routed

19.2.1. Демон routed Стандартной программой маршрутизации в Linux является демон routed. Этот демон, как правило, настраивается сам (динамически) и не требует конфигурирования. Обнаруженные маршруты он заносит в маршрутную таблицу ядра.В своей работе демон routed использует протокол

19.2.2. Демон gated — правильный выбор

19.2.2. Демон gated — правильный выбор В последнее время демон gated используется чаще, чем стандартный routed. Объясняется это тем, что gated более гибок в конфигурировании и обладает большими возможностями, в частности, им поддерживаются протоколы RIP-2 и OSFP.Программа gated была

11.6.8.2. Пара спулер/демон

11.6.8.2. Пара спулер/демон Облегченный вариант пары конфигуратор/актор может оказаться полезным в ситуациях, когда требуется сериализованный доступ к общему ресурсу в пакетном режиме, т.е. когда четко определенный поток заданий или последовательность запросов требует

11.6.8.2. Пара спулер/демон

11.6.8.2. Пара спулер/демон Облегченный вариант пары конфигуратор/актор может оказаться полезным в ситуациях, когда требуется сериализованный доступ к общему ресурсу в пакетном режиме, т.е. когда четко определенный поток заданий или последовательность запросов требует

Пердем – персональный демон

Пердем – персональный демон LinuxFormat #112 (декабрь 2008)Все знают, что пермаш – это персональная машина, пердач – персональная дача, перпен – это. нет, не то, что вы подумали, а персональная пенсия, и так далее. А вот что такое пердем? Это – персональный демон, система PC-BSD,

Источник

You may also like...