Использование спиновых вариантов в сетевой обработке

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

Я обращаюсь к глобальной структуре данных "Хэш-таблица" из контекста softirq, а также из контекста Process. Доступ к контексту процесса связан с файлом sysctl, который используется для изменения содержимого таблицы Hash.

Я использую spinlock_irq_save.

Является ли этот выбор spin_lock api правильным? С точки зрения производительности и стандартов блокировки.

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

Ответ 1

Во-первых:

Итак, со всеми приведенными выше подробностями я пришел к выводу, что мои softirq могут работать одновременно на обоих ядрах.

Да, это правильно. Ваш обработчик softirq может выполняться "одновременно на нескольких процессорах".

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

Он не должен спать (например, получить блокирующий мьютекс)
Он должен быть как можно короче

Как правило, если вы просто обновляете свою хэш-таблицу, вы должны быть в порядке.

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

Ответ 2

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