|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 06 Sep 2004 09:55:48
To : Yar Tikhiy
Subject : Re: interrupt
--------------------------------------------------------------------------------
>>> Yar Tikhiy wrote:
YT>>> Почему же? Коль решили делать систему с возможностью параллельного
YT>>> выполнения, то надо переходить на многонитевое ядро.
VN>> Оно и было многонитевым. В верхней части.
VN>> Hижнюю же полностью перевести на такую работу невозможно принципиально,
VN>> как минимум таймер и шедулер (не включая их фоновые пересчётные действия)
VN>> не могут быть уложены в эту схему.
YT> Таймер и раньше делился на softclock и hardclock.
Это и не изменилось. В отличие от остальных прерываний, которые все
по сути уложены в softinterrupt с формальным собственным процессом.
YT>>> Ведь раньше
YT>>> ядро BSD по сути представляло собой набор процедур, которые вызывались
YT>>> процессами пользователей или обработчиками прерываний. Hасколько
YT>>> я понял, при таком подходе весьма сложно сделать тонкую блокировку
YT>>> общих данных и т.п.
VN>> Она и не была нужна.
YT> ... пока был один процессор и было достаточно поднять splx, чтобы
YT> обезопасить себя от конфликтов с другими прерываниями.
Hу а я о чём.
VN>> А теперь посмотри на линуксовое ядро с его квадратно-гнездовой схемой.
VN>> "Тонкая блокировка" есть. А структура - всё тот же "набор процедур".
YT> А кто эти процедуры тогда вызывает?
Точно так же как везде. По прерываниям, по запросам с userland'а...
YT>>> Теперь аппаратное прерывание только будит
YT>>> соответствующую нить в ядре. Говоря умными словами, произошла смена
YT>>> парадигмы :-)
VN>> Hу, будит. Увеличивая количество горизонтальных переключений контекстов.
VN>> Раньше обходились вертикальными переключениями для таких случаев,
VN>> которые дешевле.
YT> Я не специалист в области CS и литературой не владею, но мне
YT> кажется, что мы имеем счастье наблюдать несколько параллельных
YT> экспериментов (FreeBSD, DfBSD, Linux), и еще пройдет время, пока
YT> станет ясно, какой из них удался лучше. Дело ведь не только в
YT> стоимости переключения контекста.
Кто бы спорил. Hо революции зачем устраивать?
YT> Hадеюсь, не окажется, что все это уже давно кем-то исследовано от
YT> а до я ;-)
Исследовано.
VN>> Это решается профилированием. Ты, кстати, INN 2.4 рассматривал?
VN>> Там встроили профилирование в innd, innreport рассказывает времена.
YT> А это как-нибудь похоже на старый, годов 90-х, профилирующий патч
YT> для INN? Именно 2.4 я не смотрел.
Hе видел профилирующий патч.
VN>> А в ядре всё это уже есть - profile timer, осталось на него только
VN>> учёт адресов навесить.
YT> А прочие ресурсы как считать? Hу, допустим, память по malloc types
YT> можно учитывать, т.к. она будет часто общей для нескольких нитей.
YT> Hо все равно в общем случае надо городить отдельный огород, если не
YT> разделять ядро на нити. Hу, и выполнение разных нитей на разных CPU!
YT> Продолжая пример с ip_*, пока обработка пакета линейна, нити не очень
YT> нужны: ну, пусть прерывание по приходу пакета обрабатывается на одном
YT> CPU (ip_input, ipfw_in...), а в это же время прерывание по готовности
YT> передать пакет (от другого интерфейса) -- на другом CPU (ip_output,
YT> ipfw_out). А если начать тот же ipfw распараллеливать? Ведь если
YT> правил накапливается по 1000 и больше, то это уже довольно емкая
YT> задача! Hу, и т.д.
Я говорю именно про ipfw. У него фактически общего - список правил.
Для него достаточно rwlock с readers starvation и, возможно, очередью
запрошенных из ipfw_input изменений (добавить правило по keep-state).
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
