Moving interrupts to threads

[Ivan Rostovikov]

Обработчики прерываний переведены на многопоточную систему работы, что позволит существенно повысить отзывчивость системы за счет ухода от блокировок;

http://lwn.net/Articles/302043/

 

Вопрос к Ядрокоту. Что теперь действительно прерывания разводятся по тредам ?

Я не совсем понял текст статьи, поэтому и спрашиваю.

Edited June 10, 2009 by Ivan Rostovikov

[photon]

Короче, сделали как во FreeBSD. Еще больше упростили top half, она теперь только подтверждает получение прерывания и бУдит соответствующий тред с bottom half. Вообще говоря, я не понимаю, чему они там в комментах так радуются: если код обработки из контекста прерываний уходит в треды, то это должно вносить задержки из-за дополнительных переключений контекста между тредами ядра и юзерскими. Для десктопа это хорошо: меньше non-preemptible кода в ядре, повышается скорость реакции на пользовательские задачи. А для скорости реакции сетевого стека -- наоборот плохо.

Edited June 11, 2009 by photon

[nuclearcat]

В 2.6.30 вроде еще этого не наблюдаю. Threaded interrupts существует, но в Linux-RT, вроде.

 

А радуются помоему по делу, для SMP точно должен быть выигрыш, в частности из-за уменьшения "глобализованных" локировок softirqd. Там еще в lwn статье много написано... хотя по сути это сильно многое не изменит. Кстати из позитивных изменений - наконец начали работать с блокировками в conntrack... У меня это одно из самых проблемных мест в транзитных рутерах.

[Max P]

таки какие-нить существенные плюсы перехода на 2.6.30 есть? стоит нат-сервер и бордер на него переводить или пока подождать?

[nuclearcat]

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

[sirmax]

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

Можно чуть подробнее или где почитать ...

 

Кстати, а зачем conntrack вообще на транзитных ...

Не думаю что не знали, но может ...

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING   -m set --set NAT_IP_1 dst       -j ACCEPT
-A PREROUTING   -m set --set NAT_IP_2 dst       -j ACCEPT
-A PREROUTING   -m set --set NAT_IP_3 dst       -j ACCEPT
-A PREROUTING                                   -j NOTRACK
COMMIT

[nuclearcat]

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

 

[photon]

А радуются помоему по делу, для SMP точно должен быть выигрыш, в частности из-за уменьшения "глобализованных" локировок softirqd. Там еще в lwn статье много написано... хотя по сути это сильно многое не изменит.

Softirq в Linux и так реализованы без giant locks. Это не 4.4BSD какая-нибудь. Просто в real-time системах и на десктопе юзерские процессы более приоритетны, чем обработка нижних половин прерываний. Threaded interrupt handlers ставит softirq на одну планку с процессами (процессорное время им тоже будет выделяться планировщиком задач). Это позволит увеличить отзывчивость пользовательских приложений за счет меньшей отзывчивости сетевого стека. Если появится опция, позволяющая выбрать ту или иную реализацию softirq при сборке ядра, то тогда будет действительно здорово.