Большое число программных прерываний в ОС Linux при приеме информации по интерфейсу CAN на AM3517, Нужно уменьшить число программных прерываний в ОС Linux Опции

[Таратухин Сергей]

У любого устройства есть свои пределы. CAN довольно неудобно обрабатывать на Линуксе. Она довольно неоднородна (имею ввиду сложность сообщений) и на каждое сообщение может требоваться индивидуальная реакция. Поэтому классический подход разгрузки прерываний в Линусе -- ПДП применить непросто, а может и невозможно.

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

Если вам будет интересно сделать CAN на другом процессоре, я лет 10 назад писал драйверы для RTOS SALVO на микрочипе. Причем там есть как с внутренним контроллером так и с подключенным как в статье по SPI. Mогу дать код.

Прерывание тупо кладет (если нет ошибок) в очередь, а тред уже забирает оттуда и обрабатывает. Система быстро выходит из прерывания, а значит имет лучше динамические характеристики.

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

[Tarbal]

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

Ну тогда я вижу только один способ уменьшить нагрузку. Сделать меньше сообщений.
Не знаю насколько это приемлимо. Дайте ваш емайл адрес в приватном сообщении и я пошлю вам примеры кода драйвера.

[AndrewN]

Кстати - в ванильном ядре и HECC NAPI поддерживает
http://lxr.free-electrons.com/source/drive.../ti_hecc.c#L604

Ну и жуткий же акцент в комментариях, страх божий... Не зря весельчаки так странно контроллер назвали, от комментариев так и хочется спросить "what the heck?!"... :)))

[Таратухин Сергей]

Кстати - в ванильном ядре и HECC NAPI поддерживает
http://lxr.free-electrons.com/source/drive.../ti_hecc.c#L604

насколько я понял
http://processors.wiki.ti.com/index.php/Si...29_Linux_Driver

у вас на процессоре такой контроллер используется.

PS я пропустил сообщение _3m
http://electronix.ru/forum/index.php?showt...t&p=1194005
он вам об этом уже говорил

Все верно, но как задействовать NAPI?

[Таратухин Сергей]

Ну тогда я вижу только один способ уменьшить нагрузку. Сделать меньше сообщений.
Не знаю насколько это приемлимо. Дайте ваш емайл адрес в приватном сообщении и я пошлю вам примеры кода драйвера.

Мне форум не дает послать вам сообщение.

[Tarbal]

Мне форум не дает послать вам сообщение.

Я попробовал послать вам, но получил такую ошибку:

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

Это личное сообщение не отправлено"

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

[Таратухин Сергей]

Я попробовал послать вам, но получил такую ошибку:

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

Это личное сообщение не отправлено"

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

У меня такая же ошибка, у меня сообщений вообще нет, так же пробовал настраивать обмен сообщениями, ни к чему положительному не привело, помощь тоже не работает.

[Tarbal]

Все верно, но как задействовать NAPI?

Для ARM архитектуры, я делаю так

В корне кернела исполнить команду:
make ARCH=arm menuconfig

Нажмите прмяой слеш : '/'
в строке поиска введите NAPI

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

[Таратухин Сергей]

Для ARM архитектуры, я делаю так

В корне кернела исполнить команду:
make ARCH=arm menuconfig

Нажмите прмяой слеш : '/'
в строке поиска введите NAPI

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

Это я делал, находил две опции:

CODE

Symbol: TULIP_NAPI [=n]
Type : boolean
Prompt: Use RX polling (NAPI)
Defined at drivers/net/tulip/Kconfig:79
Depends on: NETDEVICES [=y] && NET_ETHERNET [=y] && NET_TULIP [=n] && TULIP [=n]
Location:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Ethernet (10 or 100Mbit) (NET_ETHERNET [=y])
-> "Tulip" family network device support (NET_TULIP [=n])
-> DECchip Tulip (dc2114x) PCI support (TULIP [=n])


Symbol: TULIP_NAPI_HW_MITIGATION [=n]
Type : boolean
Prompt: Use Interrupt Mitigation
Defined at drivers/net/tulip/Kconfig:93
Depends on: NETDEVICES [=y] && NET_ETHERNET [=y] && NET_TULIP [=n] && TULIP_NAPI [=n]
Location:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Ethernet (10 or 100Mbit) (NET_ETHERNET [=y])
-> "Tulip" family network device support (NET_TULIP [=n])
-> DECchip Tulip (dc2114x) PCI support (TULIP [=n])
-> Use RX polling (NAPI) (TULIP_NAPI [=n])

но как эти опции влияют на CAN не понимаю, я их не включал. Если их включить как они повлияют на обработку приема по интерфейсу CAN и как необходимо переписать программу приема, чтоб использовать NAPI?

[Tarbal]

но как эти опции влияют на CAN не понимаю, я их не включал. Если их включить как они повлияют на обработку приема по интерфейсу CAN и как необходимо переписать программу приема, чтоб использовать NAPI?

Я не знаком с NAPI и CAN драйверы на Линуксе я тоже не делал. Полагаю, что CAN драйвер надо настроить (или дописать), чтобы использовал механизм NAPI. Если вы не работали с кернелом, то вам будет непросто выполнить эту задачу.

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

Решение задачи я вижу только в одном из направлений:
1. Снижение интенсивности сообщений
2. Использование более мощного процессора.
3. Установка дополнительного устройства, ответственного за обработку (хотя бы частичную) сообщений.

В третьем случае может понадобится написать драйвер.

[sasamy]

Это я делал, находил две опции:
..
но как эти опции влияют на CAN не понимаю, я их не включал.

Эти - никак не влияют.

как необходимо переписать программу приема, чтоб использовать NAPI?

Ничего переписывать не надо - NAPI должен поддерживать драйвер, некоторые делают опциаональные настройки - выбор между обычным и New API, у вашего контроллера NAPI используется всегда

http://lxr.free-electrons.com/source/drive.../ti_hecc.c#L860

почему поллинг не снижает количество прерываний - это надо разбираться с этим драйвером и контроллером.

[AndrewN]

почему поллинг не снижает количество прерываний - это надо разбираться с этим драйвером и контроллером

Коллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 128KB/s, т.е. цыплячья скорость UARTа, и это нагружает Ослинукс на 600 мегагерцовом процессоре???? Я или сам ослинукс или мне просто смешно...

Интервал между двумя последовательными байтами 4,700 клоков - этого мало _один_ байт обработать???? А 0.8 на шине, т.е. 0.8*128 это уже 5,900 клоков на байт - за такое время не только пообедать, но и посуду можно вымыть...

[A. Fig Lee]

Коллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 128KB/s, т.е. цыплячья скорость UARTа, и это нагружает Ослинукс на 600 мегагерцовом процессоре???? Я или сам ослинукс или мне просто смешно...

Интервал между двумя последовательными байтами 4,700 клоков - этого мало _один_ байт обработать???? А 0.8 на шине, т.е. 0.8*128 это уже 5,900 клоков на байт - за такое время не только пообедать, но и посуду можно вымыть...

Мда..

Вы линукс то видали?
Сколько там процессов/тредов бежит смотрели?

[Tarbal]

Коллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 128KB/s, т.е. цыплячья скорость UARTа, и это нагружает Ослинукс на 600 мегагерцовом процессоре???? Я или сам ослинукс или мне просто смешно...

Интервал между двумя последовательными байтами 4,700 клоков - этого мало _один_ байт обработать???? А 0.8 на шине, т.е. 0.8*128 это уже 5,900 клоков на байт - за такое время не только пообедать, но и посуду можно вымыть...

Цыплячья скорость UART в 10 раз ниже 115kBit/S. У UART сообщения однобайтовые и все. У CAN надо каждое сообщение обрабатывать. Значит ПДП не обойдешься как можно было бы на UART сделать.

Сколько времени занимает вход в в прерывание (~5uS)? Умножте это на 2000 (128000/64). Столько времени надо отдать на накладные расходы каждую секунду. Идет борьба за это время.
2000*5uS = 10mS. Что есть один процент. Похоже вы правы. Надо исследовать и найти что пожирает время.

Я честно боролся за оптимизацию


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

Могу помочь найти как сконфигурировать ножки и место куда вставить команды.

Мда..

Вы линукс то видали?
Сколько там процессов/тредов бежит смотрели?

Как я понял разница когда есть поток сообщений и когда нет отличаются на 60% занятости процессора.

Сообщение отредактировал Tarbal - Sep 24 2013, 00:49

[AndrewN]

Цыплячья скорость UART в 10 раз ниже 115kBit/S

Упс..., промашку давал... Утячья скорость получается - в полёте... :)

Сколько времени занимает вход в в прерывание (~5uS)? Умножте это на 2000 (128000/64)

Интересно. Т.е. 1 интеррапт на каждые 64 байта? Это облегчает задачу. EDMA же привязана к ивенту, она и сложит эти 64 байта в угол, т.е. в буфер...

5 микросек это 3000 клоков процессора. На вход многовато, вход прост (разумно предположить такое?), а вот выход сложнее из-за перепланировки (знать бы алгоритм...). Ну условно можно считать, что 5 на вход и выход - разумное число. Хотя, это же Ослинукс, кто его разберёт... При 0.8 загрузке 5,900*64 клоков на 64 байта это 377К, от коего числа 3К на оверхед интеррапта составляет 0.0079 - т.е. 8 промилле. Меньше, чем процент.

Сообщение отредактировал AndrewN - Sep 24 2013, 03:06