Ivan Rostovikov Опубликовано 10 июня, 2009 (изменено) · Жалоба Обработчики прерываний переведены на многопоточную систему работы, что позволит существенно повысить отзывчивость системы за счет ухода от блокировок; http://lwn.net/Articles/302043/ Вопрос к Ядрокоту. Что теперь действительно прерывания разводятся по тредам ? Я не совсем понял текст статьи, поэтому и спрашиваю. Изменено 10 июня, 2009 пользователем Ivan Rostovikov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 11 июня, 2009 (изменено) · Жалоба Короче, сделали как во FreeBSD. Еще больше упростили top half, она теперь только подтверждает получение прерывания и бУдит соответствующий тред с bottom half. Вообще говоря, я не понимаю, чему они там в комментах так радуются: если код обработки из контекста прерываний уходит в треды, то это должно вносить задержки из-за дополнительных переключений контекста между тредами ядра и юзерскими. Для десктопа это хорошо: меньше non-preemptible кода в ядре, повышается скорость реакции на пользовательские задачи. А для скорости реакции сетевого стека -- наоборот плохо. Изменено 11 июня, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 11 июня, 2009 · Жалоба В 2.6.30 вроде еще этого не наблюдаю. Threaded interrupts существует, но в Linux-RT, вроде. А радуются помоему по делу, для SMP точно должен быть выигрыш, в частности из-за уменьшения "глобализованных" локировок softirqd. Там еще в lwn статье много написано... хотя по сути это сильно многое не изменит. Кстати из позитивных изменений - наконец начали работать с блокировками в conntrack... У меня это одно из самых проблемных мест в транзитных рутерах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 11 июня, 2009 · Жалоба таки какие-нить существенные плюсы перехода на 2.6.30 есть? стоит нат-сервер и бордер на него переводить или пока подождать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 11 июня, 2009 · Жалоба Пофикшенный баг с удаляющимися интерфейсами... в остальном, если нет нужды - лучше подождать недельку, если машинки нагруженные и не дублируются. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 12 июня, 2009 · Жалоба наконец начали работать с блокировками в 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 12 июня, 2009 · Жалоба У меня много ассимметрии, аплинк там, даунлинк сям, редиректы на проксю где попало (CTO очень умный, захотел так), еще и куча маленьких каналов, вместо двух-трех нормальных. Там где можно - убрал конечно, но и не везде raw прислонишь, хотя он и имеется. От блокировок самого iptables он не спасает, кстати. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 15 июня, 2009 · Жалоба А радуются помоему по делу, для SMP точно должен быть выигрыш, в частности из-за уменьшения "глобализованных" локировок softirqd. Там еще в lwn статье много написано... хотя по сути это сильно многое не изменит. Softirq в Linux и так реализованы без giant locks. Это не 4.4BSD какая-нибудь. Просто в real-time системах и на десктопе юзерские процессы более приоритетны, чем обработка нижних половин прерываний. Threaded interrupt handlers ставит softirq на одну планку с процессами (процессорное время им тоже будет выделяться планировщиком задач). Это позволит увеличить отзывчивость пользовательских приложений за счет меньшей отзывчивости сетевого стека. Если появится опция, позволяющая выбрать ту или иную реализацию softirq при сборке ядра, то тогда будет действительно здорово. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...