Как заставить ядро ​​Linux «зависать» (или почти зависать) на несколько сотен миллисекунд

Мы запускаем процесс в реальном времени на ядре не в реальном времени (CentOS 6), и это, вероятно, не изменится.

У нас есть приложение для потокового видео, которое требует около 500 МБ / с трафика PCIe от пользовательской FPGA непрерывно в течение 1,5 часов за один раз. Приложение работает довольно хорошо - большую часть времени. Однако у нас были ситуации, когда казалось, что ядро ​​просто перестало отвечать на запросы PCIe или памяти на 500 миллисекунд за раз. Это происходит во время пакетного ввода-вывода файла из другого потока. Я обнаружил, что невозможно попытаться воспроизвести эту проблему, просто выполняя много пустых операций ввода-вывода файлов из пространства пользователя во время работы основного приложения.

Есть ли способ принудительно (симулировать) глобальное «замораживание» ядра Linux (в частности, остановка PCIe или всех обращений к памяти DDR3 или что-то в этом роде), чтобы мы могли воспроизвести эту проблему?

Мы встроили буферизацию до 10 миллисекунд прямо сейчас во внутреннюю память FPGA, но этого недостаточно. Мы можем выполнить буферизацию на FPGA DDR3 и затем выполнить дамп на хост, но нам нужен метод для тестирования этой новой функции под принуждением.

Мы не хотим, чтобы ядро ​​постоянно зависало или зависало. Мы хотели бы возможность установить временной интервал.

Я ищу что-то вроде записи магических значений для /proc/sys/vmвременного, что делает систему практически ползающей, а затем возвращается через несколько сотен миллисекунд, но я смотрю на количество возможных способов сломать это не для новичка, как я ( https://www.kernel.org/doc/Documentation/sysctl/vm.txt ). Может быть, немного numactlмагии?

Одним из вариантов быстрого тестирования может быть использование ядра с поддержкой KGDB, остановка ядра вручную и проверка, см. Эту ссылку .

С другой стороны, то, что я помню, могло вызвать ваши паузы:

• cpufreq, cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latencyзначение в нс (4000 в моем 8-ядерном процессоре AMD FX (tm) -8120) не должно быть проблемой, но проверьте
• Термическое дросселирование либо самого процессора, либо модуля регулятора напряжения.
• NAPI и / или интенсивный сетевой трафик
• PCIe ASPM ( cat /sys/module/pcie_aspm/parameters/policy)
• Конфликт в буферах целевого устройства (жесткий диск, ник ...)
• Ошибка в прошивке какого-либо устройства в шине PCIe (даже если вы не используете его), вы можете попробовать отключить их с помощью /sys/bus/pci/devices/$DEVICE/power/control

Можем ли мы получить более подробную информацию о том, как ваше приложение взаимодействует с FPGA? Это приложение, которое считывает буфер из FPGA, или FPGA, которая отправляет прерывания ядру (например, сетевые карты)?

Я ожидаю, что он откроет блок / символ в / dev и затем свяжется с ним. Это означает, что он использует драйвер для связи между приложением и файлом / dev / XXX.

Я хотел бы получить вывод cat /proc/interrupts:; lsmod;ls -al /dev/yourmod

Вот идеи:

• Если он управляется прерываниями, вы можете настроить PIC ЦП на отключение соответствующего IRQ, а затем снова включить его. Это приведет к тому, что каждый запрос карты будет игнорироваться (без ведома карты об этом).
• если это похоже на чтение из буфера, вы можете:
  • Переведите ваше приложение в состояние сна, чтобы данные из FPGA не читались, и ваш буфер заполнился, затем разбудил ваше приложение и продолжил чтение.
  • Используйте «crash» или «kgdb», чтобы изменить значение «read» на «noop» на несколько секунд, а затем вернуть его к функции по умолчанию.

Пожалуйста, предоставьте всю информацию, которая может оказаться вам полезной.

Не уверен, что это поможет. Но если вы можете написать модуль ядра, который вызывает suspendфункцию модуля ядра другого устройства, это может сделать.

Каждое PCI-устройство может быть приостановлено в соответствии с заголовочным файлом http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/pci.h#L479.

Например, вот функция приостановки сетевого адаптера Intel e1000 http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/drivers/net/e1000e/netdev.c#L4643

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

Я думаю, что вы думаете по неправильному пути. Ваша цель ясна.

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

Более сложной проблемой является обработка прерываний PCIe, которая находится в пространстве ядра.

Поскольку аппаратное обеспечение задействовано, вам следует поближе познакомиться с задействованной линией PCIe на материнской плате и с тем, как она, возможно, подключена к конкретному сокету процессора.

Обычно irqbalance отлично справляется с этой задачей, но вы можете настроить его поведение в соответствии с вашими потребностями.