Size: a a a

2020 February 20

LS

Lev Serebryakov in freebsd_ru
Vyacheslav Olkhovchenkov
ну тогда ты никак не решашь вот эту задачу "Но встаёт вопрос — вот ты mbuf оттуда удалил, а когда его убивать? Вдруг пока ты его удалял его кто0то взял (указатель на него) в локальную переменную и пямощас работает?"
Именно эту. Живой коннект не будет всё время жить в локальных переменных, он вернётся в очередь живых
источник

LS

Lev Serebryakov in freebsd_ru
И пока он живой не будет даже вопроса о перекладывании ешго в очередь мёртвых, к уаделнию
источник

LS

Lev Serebryakov in freebsd_ru
И эпохи тут будут вовсе не при чём
источник

LS

Lev Serebryakov in freebsd_ru
О, даже Адриана с этими эпохами разбудили: r358156 | adrian
источник

AF

Alexander Fedorov in freebsd_ru
Так mbuf's все по старинке обрабатываются
источник

LS

Lev Serebryakov in freebsd_ru
Alexander Fedorov
Так mbuf's все по старинке обрабатываются
mbuf'ы это первое что пришло мне в голову. Адреса на интерфейсе вот, например ещё. Рауты.
источник

AF

Alexander Fedorov in freebsd_ru
Вот пример как раз, адреса на интерфейсе в том же нетграфе http://bxr.su/FreeBSD/sys/netgraph/ng_eiface.c#517
источник

VO

Vyacheslav Olkhovchenkov in freebsd_ru
мне первое что в голову пришло -- это inpcb
источник

VG

Vadim Goncharov in freebsd_ru
Lev Serebryakov
Ну смотри. У тебя есть, скажем, очередь mbuf'ов. Не фокус сделать без локов добавление туда mbuf'а и удаление оттуда mbuf'а. На CAS'ах.
Но встаёт вопрос — вот ты mbuf оттуда удалил, а когда его убивать? Вдруг пока ты его удалял его кто0то взял (указатель на него) в локальную переменную и пямощас работает?
Мы добавляем его в список "к удалению, добавлен в эпоху X".
Когда все сказали что они закончили с эпохой X можно чистить этот список на удаление до эпохи X.
вроде звучит как довольно старая идея
источник

AE

Andrey Elsukov in freebsd_ru
вот пример из динамических стейтов: у тебя есть куча SLIST'ов в хеш таблице, её элементы это стейты. Используя epoch, ты можешь без локов искать среди всех этих элементов нужный стейт. У тебя есть гарантия, что код который чистит стейты по таймауту в какой-то момент не возьмёт и не освободит память, пока к ней пытается обращаться код на другом ядре.
источник

AE

Andrey Elsukov in freebsd_ru
и у тебя не будет page fault
источник

LS

Lev Serebryakov in freebsd_ru
Vadim Goncharov
вроде звучит как довольно старая идея
Ну, она не новая, прямо скажем. Как и всё. RCU по сути устроен так же, а это IBM'овский патент чуть не 80-х годов прошлого века.
Тут, как всегда, дьявол в деталях — как эффективно сделать вход-выход из эпохи на многоядерном железе
источник

VO

Vyacheslav Olkhovchenkov in freebsd_ru
что-то в мане пример какой-то мутный. совершенно непонятно как все три треда между собой связанны
источник

LS

Lev Serebryakov in freebsd_ru
Заметим, что это довольно специфический, но GC. И как любой GC он увеличивает потребление памяти. Мы (ну, такое, широкое мы) надеемся, что этим мы покупаем throughput, так как существенно уменьшаем число блокирующих операций.
источник

VO

Vyacheslav Olkhovchenkov in freebsd_ru
да у нас и так полно GC в ядре. уж я-то знаю.
источник

AE

Andrey Elsukov in freebsd_ru
ну да, вот одна из недавних проблем, интеловцы жаловались. у них есть ixl драйвер, который обрабатывает большой поток pps, они делают kldunload if_ixl, и всё. Там при выгрузке делается epoch_drain, который не может никак завершиться
источник

VO

Vyacheslav Olkhovchenkov in freebsd_ru
Andrey Elsukov
вот пример из динамических стейтов: у тебя есть куча SLIST'ов в хеш таблице, её элементы это стейты. Используя epoch, ты можешь без локов искать среди всех этих элементов нужный стейт. У тебя есть гарантия, что код который чистит стейты по таймауту в какой-то момент не возьмёт и не освободит память, пока к ней пытается обращаться код на другом ядре.
я не понял, кто стейт? отдельный SLIST или отдельный элемент SLIST?
источник

AE

Andrey Elsukov in freebsd_ru
стейт это отдельный элемент в SLIST
источник

AE

Andrey Elsukov in freebsd_ru
хеш таблица - это массив из этих SLIST
источник

VO

Vyacheslav Olkhovchenkov in freebsd_ru
ну тогда почему у нас нет проблемы с тем, что пока мы трверсим -- кто-то ненужный нам элемент выкинет и мы по ссылкам придем в жопу? просто траверся.
источник