Jump to content
Калькуляторы

Moving interrupts to threads 2.6.30 это круто ?

Обработчики прерываний переведены на многопоточную систему работы, что позволит существенно повысить отзывчивость системы за счет ухода от блокировок;
http://lwn.net/Articles/302043/

 

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

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

Edited by Ivan Rostovikov

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
наконец начали работать с блокировками в 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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this