|
|
  |
Большое число программных прерываний в ОС Linux при приеме информации по интерфейсу CAN на AM3517, Нужно уменьшить число программных прерываний в ОС Linux |
|
|
|
Sep 18 2013, 09:49
|
Группа: Участник
Сообщений: 14
Регистрация: 18-09-13
Пользователь №: 78 372

|
На AM3517 при получении информации через интерфейс CAN (скорость передачи данных 1 Мбит/с шина CAN загружена около 80%) в ОС Linux генерируется много программных прерываний (около 45% загрузки процессора). Можно ли уменьшить количество программных прерываний при приеме?
|
|
|
|
|
Sep 18 2013, 19:24
|
Знающий
   
Группа: Участник
Сообщений: 745
Регистрация: 28-12-06
Пользователь №: 23 960

|
Цитата(Tarbal @ Sep 18 2013, 21:00)  Уточните насчет программных прерываний. Может все-таки это реальные прерывания вызванные железом? Если так, то число прерываний должно совпадать с числом принятых сообщений, переданых сообщений и еще какой-нибудь байды, которая разрешена. Я посмотрел драйвер TI тот что в mainline. Там обработка приема делается поллингом так что количество хардверных прерываний от кан интерфейса будет меньше либо равно количеству принятых пакетов. С подтверждением прерываний может быть проблема это есть смысл проверить. Также не исключено что высокая загрузка это норма для скорости 1М. Ядро обрабатывает принятые пакеты софтверно. Какой софт у вас получает пакеты ?
|
|
|
|
|
Sep 19 2013, 05:54
|
Группа: Участник
Сообщений: 14
Регистрация: 18-09-13
Пользователь №: 78 372

|
Цитата(_3m @ Sep 19 2013, 01:24)  Я посмотрел драйвер TI тот что в mainline. Там обработка приема делается поллингом так что количество хардверных прерываний от кан интерфейса будет меньше либо равно количеству принятых пакетов. С подтверждением прерываний может быть проблема это есть смысл проверить. Также не исключено что высокая загрузка это норма для скорости 1М. Ядро обрабатывает принятые пакеты софтверно. Какой софт у вас получает пакеты ? Чтобы проверить прием была написана технологическая программа. Она ни чего не выводит, просто читает из сокета пакеты CAN в фоновом режиме и увеличивает счетчик принятых пракетов (по шине CAN непрерывно передается информация). Загрузку смотрю утилитой top. Так же привожу кол-во прерываний, кол-во принятых пакетов и размер принятых данных (cat /proc/interrupts ; ifconfig). CODE Mem: 32336K used, 204116K free, 0K shrd, 1568K buff, 6260K cached CPU: 0% usr 21% sys 0% nic 35% idle 0% io 0% irq 42% sirq Load average: 0.03 0.04 0.05 1/58 1009 PID PPID USER STAT VSZ %MEM %CPU COMMAND 1008 951 root R 1472 1% 44% ./a.out 622 2 root SW 0 0% 6% [kworker/0:2] 644 2 root SW 0 0% 1% [ksdioirqd/mmc1] 1009 951 root R 2844 1% 1% top 45 2 root SW 0 0% 0% [irq/74-serial i] 951 949 root S 2844 1% 0% -sh 924 1 root S 2732 1% 0% /sbin/syslogd -n -C64 -m 20 926 1 root S 2668 1% 0% /sbin/klogd -n 917 1 root S 2668 1% 0% /usr/sbin/telnetd 912 1 messageb S 2436 1% 0% /usr/bin/dbus-daemon --system 949 1 root S 2400 1% 0% login -- root 692 1 root S < 2188 1% 0% /sbin/udevd -d 726 692 root S < 2184 1% 0% /sbin/udevd -d 727 692 root S < 2184 1% 0% /sbin/udevd -d 933 1 root S 2064 1% 0% /usr/sbin/thttpd -d /srv/www -p 8080 - 1 0 root S 1628 1% 0% init [5] 588 2 root SW 0 0% 0% [w1_bus_master1] 5 2 root SW 0 0% 0% [kworker/u:0] 633 2 root SW 0 0% 0% [mmcqd/0] 3 2 root SW 0 0% 0% [ksoftirqd/0] CODE root@am3517-evm:~# cat /proc/interrupts ; ifconfig CPU0 11: 0 INTC prcm 12: 1873 INTC DMA 20: 0 INTC gpmc 24: 12114477 INTC can0 25: 2 INTC OMAP DSS 37: 454780 INTC gp timer 56: 1874385 INTC omap_i2c 57: 0 INTC omap_i2c 58: 84972 INTC omap_hdq 61: 0 INTC omap_i2c 71: 1 INTC musb-hdrc.0 72: 0 INTC serial idle 73: 0 INTC serial idle 74: 22509 INTC serial idle, OMAP UART2 77: 0 INTC ehci_hcd:usb2 83: 2765 INTC mmc0 86: 286560 INTC mmc1 160: 0 GPIO tps6507x 162: 1 GPIO mmc1 184: 0 GPIO ds1374 186: 0 GPIO tca8418-keypad 224: 0 GPIO mmc0 Err: 0
can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP RUNNING NOARP MTU:16 Metric:1 RX packets:12732263 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:88788609 (84.6 MiB) TX bytes:0 (0.0 B) Interrupt:24 CODE 1 #include <stdio.h> 2 #include <sys/types.h> 3 #include <sys/socket.h> 4 #include <sys/ioctl.h> 5 #include <net/if.h> 6 7 #include <linux/can.h> 8 #include <linux/can/raw.h> 9 #include <string.h> 10 11 /* At time of writing, these constants are not defined in the headers */ 12 #ifndef PF_CAN 13 #define PF_CAN 29 14 #endif 15 16 #ifndef AF_CAN 17 #define AF_CAN PF_CAN 18 #endif 19 20 int main(int argc, char *argv[]) 21 { 22 /* create a frame */ 23 struct can_frame frame; 24 /* interface */ 25 struct ifreq ifr; 26 /* number of te */ 27 int bytes_read; 28 /* create the socket */ 29 int skt = socket( PF_CAN, SOCK_RAW, CAN_RAW ); 30 /* socket address */ 31 struct sockaddr_can addr; 32 /* counter SFF */ 33 unsigned long countSFF; 34 /* counter EFF*/ 35 unsigned long countEFF; 36 37 countSFF = 0; 38 countEFF = 0; 39 /* locate the interface you wish to use */ 40 strcpy( ifr.ifr_name, "can0" ); 41 ioctl( skt, SIOCGIFINDEX, &ifr ); /* ifr.ifr_ifindex gets filled with that device's index */ 42 /* select that CAN interface, and bind the socket to it. */ 43 addr.can_family = AF_CAN; 44 addr.can_ifindex = ifr.ifr_ifindex; 45 bind( skt, ( struct sockaddr * ) &addr, sizeof( addr ) ); 46 while(1) 47 { 48 bytes_read = read( skt, &frame, sizeof( frame ) ); 49 if( bytes_read < 0 ) 50 { 51 printf( "CAN\n" ); 52 } 53 else if ( bytes_read > 0 ) 54 { 55 if( !( frame.can_id & 0x80000000U ) ) 56 { 57 countSFF++; 58 } 59 else 60 { 61 countEFF++; 62 } 63 } 64 } 65 66 return 0; 67 } Цитата(kurtis @ Sep 18 2013, 18:45)  У вас случайно прерывания не по gpio идут? Если по gpio, то по фронту или по уровню? Прерывания CAN осуществляется не по GPIO (фрагмент из команды "cat /proc/interrupts" 24: 12114477 INTC can0). Цитата(Tarbal @ Sep 19 2013, 07:13)  Положим одна транзакция 100 бит. Значит при 80% загрузке в секунду приходит 8000 сообщений. А сколько у вас прерываний случается? Из "cat /proc/interrupts" следует, что за несколько минут, при загрузки шины CAN примерно 80% количество прерываний 12114477.
|
|
|
|
|
Sep 19 2013, 07:16
|
Знающий
   
Группа: Участник
Сообщений: 745
Регистрация: 28-12-06
Пользователь №: 23 960

|
Цитата(Таратухин Сергей @ Sep 19 2013, 09:54)  Чтобы проверить прием была написана технологическая программа. Она ни чего не выводит, просто читает из сокета пакеты CAN в фоновом режиме и увеличивает счетчик принятых пракетов ... Пока не вижу криминала. По вашим данным 12114477 INTC can0 12732263 RX packets У вас 0,95 прерывания на пакет. Абсолютное большинство пакетов система успевает забрать и обработать до прихода следующего. Возможно это нормальная работа socketcan. Там довольно накручено поэтому еще живы альтернативные решения, например lincan. Вот бенчмарки CAN driver benchmarkВ бенчмарке есть хорошая идея - тестировать socketcan при одновременной нагрузке ethernet. Цитата(Tarbal @ Sep 19 2013, 05:13)  Положим одна транзакция 100 бит. Значит при 80% загрузке в секунду приходит 8000 сообщений. А сколько у вас прерываний случается? По моим расчетам (я мог ошибиться) для скорости 1М максимальный темп передачи пакетов CAN при 100% загрузке шины и длине данных 8 бит составляет 63 и 81мкс для стандартных и расширенных пакетов соответственно что дает 15873 и 12345 пакетов в секунду. У ТС загрузка шины 80% значит пакеты поступают каждые 79мкс.
|
|
|
|
|
Sep 19 2013, 13:19
|
Профессионал
    
Группа: Свой
Сообщений: 1 351
Регистрация: 21-05-10
Пользователь №: 57 439

|
Цитата(_3m @ Sep 19 2013, 11:16)  Пока не вижу криминала. По вашим данным 12114477 INTC can0 12732263 RX packets У вас 0,95 прерывания на пакет. Абсолютное большинство пакетов система успевает забрать и обработать до прихода следующего. Возможно это нормальная работа socketcan. Там довольно накручено поэтому еще живы альтернативные решения, например lincan. Вот бенчмарки CAN driver benchmarkВ бенчмарке есть хорошая идея - тестировать socketcan при одновременной нагрузке ethernet. По моим расчетам (я мог ошибиться) для скорости 1М максимальный темп передачи пакетов CAN при 100% загрузке шины и длине данных 8 бит составляет 63 и 81мкс для стандартных и расширенных пакетов соответственно что дает 15873 и 12345 пакетов в секунду. У ТС загрузка шины 80% значит пакеты поступают каждые 79мкс. Ваши рассчеты точнее моих. Я просто оценил порядок величины. Похоже система работает правильно. На каждый принятый пакет прерывание. Просто пакетов много.
|
|
|
|
|
Sep 20 2013, 09:13
|
Группа: Участник
Сообщений: 14
Регистрация: 18-09-13
Пользователь №: 78 372

|
Цитата(Tarbal @ Sep 19 2013, 19:19)  Ваши рассчеты точнее моих. Я просто оценил порядок величины. Похоже система работает правильно. На каждый принятый пакет прерывание. Просто пакетов много. Проанализировал ситуацию (после прочтения предложений участников) и посмотрел в интернете насчет LinCAN наткнулся на одну интересную статью CAN driver benchmarkВ итоге пришел к выводу, что эта проблема драйвера и механизма доступа к нему, который реализовали сотрудники TI. Так что AM3517 с драйвером CAN от TI не обеспечивает низкую загрузку центрального процессора при приеме CAN пакетов сильно загруженной шины CAN. Буду уменьшать загрузку шины CAN, чтобы уменьшить нагрузку на центральный процессор при приеме. Всем спасибо за помощь.
Сообщение отредактировал Таратухин Сергей - Sep 20 2013, 09:15
|
|
|
|
|
Sep 20 2013, 12:23
|
Группа: Участник
Сообщений: 14
Регистрация: 18-09-13
Пользователь №: 78 372

|
Цитата(sasamy @ Sep 20 2013, 16:42)  В статье описан типичный поллинг - ISR отрабатывает первый пакет а остальные (если они есть) отрабатываются в контексте soft irq (bottom half) или обычного процесса проверкой бита готовности данных. Для ethernet в ядре есть готовый механизм - NAPI. В общем техника широко применяемая. Про методику читал (NAPI), но как им пользоваться не знаю (найти примеры не получилось). Если есть возможность рассказать про этот механизм подробнее буду очень благодарен. Цитата(A. Fig Lee @ Sep 20 2013, 18:11)  Не знаю везде ли, но у СТМ и майкрочипа фильтр стоит на ИД, принимает только те, которые нужно Фильтровать на аппаратном уровне могу (необходимо принимать примерно 15% от максимальной загрузки шины, при этом нагрузка центрального процессора действительно маленькая порядка 4-7%), но есть ситуации когда необходимо будет принять большой объем пакетов (примерно 80% загрузки шины).
Сообщение отредактировал Таратухин Сергей - Sep 20 2013, 12:24
|
|
|
|
|
Sep 20 2013, 12:30
|
Профессионал
    
Группа: Свой
Сообщений: 1 351
Регистрация: 21-05-10
Пользователь №: 57 439

|
Цитата(Таратухин Сергей @ Sep 20 2013, 13:13)  Проанализировал ситуацию (после прочтения предложений участников) и посмотрел в интернете насчет LinCAN наткнулся на одну интересную статью CAN driver benchmarkВ итоге пришел к выводу, что эта проблема драйвера и механизма доступа к нему, который реализовали сотрудники TI. Так что AM3517 с драйвером CAN от TI не обеспечивает низкую загрузку центрального процессора при приеме CAN пакетов сильно загруженной шины CAN. Буду уменьшать загрузку шины CAN, чтобы уменьшить нагрузку на центральный процессор при приеме. Всем спасибо за помощь. У любого устройства есть свои пределы. CAN довольно неудобно обрабатывать на Линуксе. Она довольно неоднородна (имею ввиду сложность сообщений) и на каждое сообщение может требоваться индивидуальная реакция. Поэтому классический подход разгрузки прерываний в Линусе -- ПДП применить непросто, а может и невозможно. Я уверен что процессор без ОС или с какой-нибудь реал-тайм ОС покажет лучшие результаты чем Линукс. Дело в том, что в Линуксе плата за универсальность долгий вход в обработчик прерывания. Если вам будет интересно сделать CAN на другом процессоре, я лет 10 назад писал драйверы для RTOS SALVO на микрочипе. Причем там есть как с внутренним контроллером так и с подключенным как в статье по SPI. Mогу дать код. Прерывание тупо кладет (если нет ошибок) в очередь, а тред уже забирает оттуда и обрабатывает. Система быстро выходит из прерывания, а значит имет лучше динамические характеристики.
Сообщение отредактировал Tarbal - Sep 20 2013, 13:25
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|