Re: [Fwd: Re: как зажать вход]

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: как зажать вход]

Anton Maksimenkov-2
Ой, сорри, я полагал это в лист уйдёт. Интересная тема, чо бы не
оставить в архиве, а?

12 февраля 2009 г. 13:40 пользователь engineer <[hidden email]> написал:

>> По твоей же теме (pppoe) есть вариант слегка попроще: воспользоваться
>> pppoe(8), а все управление трафиком возложить на ppp.
> Я знал что ты это скажешь. (с)
>
> Есть одно больше НО. PPP это есть юзерспейс, со всеми вытекающими. А
> конкретно - где-то чуваки писали, пробовали ставить опёнок в данную
> позу, получили максимум неск-ко мегабит В ОБЩЕМ. Если только один
> клиент в наличии...
> Словом, ни в какую не провайдерский вариант. Не хочу тут холивара,
> просто конкурирующая фирма, при всём сраче, имеет рабочий вариант. На
> этом наверно аллес, ибо это это.
>
>> Насчет же того, как получить нужный эффект без промежуточной машины -
>> по-моему ответ очевиден: надо не зацикливаться на одном PF.
>> Попросту говоря, никто не заставляет пакеты, принятые на интерфейсе отдавать
>> в стек.
> Ого. Да, Тео шутник. Чтобы такое ухватить, это да, надо настолько
> читать, что я даже хрен бы знал где такое прочитать... Он наверно имел
> ввиду "не умеют читать код ядра"... А? :-)))
>
>> Самый простой способ - реальный интерфейс просто поднимаем, но не даем ему
>> никакого адреса, слушаем его через BPF, делаем все что
>> хотим в плане задержек, очередей да и вообще все что взбредет в голову и в
>> конечном итоге отдаем в созданный tun интерфейс (который
>> работает в режиме ethernet если нужно).
>
> Ну и без шуток, это уже интересно (не в плане применения, но в плане
> понимания), можно более детальное описание как скрестить ежа с ужом? А
> то я чот даже не представляю, что в себя включает такой дикий хак. Что
> представляет из себя "отдаём в tun интерфейс"?
> Или это имелось ввиду что на Сях написать и... и чо? Словить на bpf
> пакет, распарсить, сформировать новый, запихать... как-то... в tun? О
> боже, неужели это правда...
> И ещё. Если так, то это ж получается опять из ядра в юзерспейс и
> обратно гонять весь поток. Получим опять что машинка от силы единицы
> мегабит пережует...
>
> Я даже боюсь спросить... А что, есть другие способы? Намекни?
>
> А вообще, да, form@, пешиестчо! Благодаря в том числе тебе, уже не раз
> открываю для себя новые стороны униксов. Щас вот взглянул в ман,
> покумекал... Этож блин какая штука получается, страсть. Тока надо
> вагон мотивации, чтобы всё это воплотить в С-код и долизать до
> рабочего состояния.
> Как оффтопик подумал даже такое - а ведь можно замутить даже аналог
> такой хрени как ip-unnumbered на VLAN-интерфейсах... Аж волосы на
> башке зашевелились. :-))))) Всё конечно упирается в то, что это всё в
> юзерспейсе, маловато производительности будет. Если уж пилить, так
> придумывать чоттип модуля ядра. Может даже твой ipflow как пример
> ядерного модуля взять...
> Вощем, пасиб, порадовался.
>
> Dinar Talypov <[hidden email]> написал:
>>> Для того, чтобы предоставить каждому из N IP-адресов свою полосу, скажем, в 1%
>>> нужно создать N очередей
>>  А стоит ли это делать для каждого IP?
> Ну а как... С точки зрения провайдера (ну и юзера, подсознательно)
> надо бы сделать так, чтобы каждый IP имел свою очередь Ххб/с, и,
> независимо от остальных, мог более-менее гарантированно иметь эти свои
> Ххб/с. Желательно также, чтобы если канал "недоиспользован", то он
> поровну делился на эти Ххб/с, согласно количеству "активных
> пользователей" в этот момент (ну, Х возрастает, да?).
> По-мойму так! (с) В.Пух
>
> ЗЫЖ ещё бы SMP продвигалось, было б совсем интересно. Кстати, что там
> слышно "в кругах", конкурирующая SMPng оно к опёнку никак не это...?
> Ну хотяб в плане источника идей и примеров реализации.
> --
> engineer
>



--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: как зажат

Mike Belopuhov
On Thu, Feb 12, 2009 at 13:46 +0500, engineer wrote:

> >> Самый простой способ - реальный интерфейс просто поднимаем, но не даем ему
> >> никакого адреса, слушаем его через BPF, делаем все что
> >> хотим в плане задержек, очередей да и вообще все что взбредет в голову и в
> >> конечном итоге отдаем в созданный tun интерфейс (который
> >> работает в режиме ethernet если нужно).
> >
> > Ну и без шуток, это уже интересно (не в плане применения, но в плане
> > понимания), можно более детальное описание как скрестить ежа с ужом? А
> > то я чот даже не представляю, что в себя включает такой дикий хак. Что
> > представляет из себя "отдаём в tun интерфейс"?
> > Или это имелось ввиду что на Сях написать и... и чо? Словить на bpf
> > пакет, распарсить, сформировать новый, запихать... как-то... в tun? О
> > боже, неужели это правда...
> > И ещё. Если так, то это ж получается опять из ядра в юзерспейс и
> > обратно гонять весь поток. Получим опять что машинка от силы единицы
> > мегабит пережует...
> >

известный факт что большинство тормозов юзерленда из-за универсального
интерфейса сокетов.  весь (часть) TCP/IP стек(а) можно вынести в юзерланд,
выкинув весь software intrrupt процессинг.  в тун запихнуть можно тем же
bpf'ом.

опять же pf это фактически до -100Mbit/s.  в частности из-за "scrub in".

> > ЗЫЖ ещё бы SMP продвигалось, было б совсем интересно. Кстати, что там
> > слышно "в кругах", конкурирующая SMPng оно к опёнку никак не это...?
> > Ну хотяб в плане источника идей и примеров реализации.

SMPng это из фри?  Никак не помогает.
А так надо много чего чинить, даже если хочется чтобы базовые spl'и
превратились в мутексы.


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: как зажат

Anton Maksimenkov-2
>> > И ещё. Если так, то это ж получается опять из ядра в юзерспейс и
>> > обратно гонять весь поток. Получим опять что машинка от силы единицы
>> > мегабит пережует...
>
> известный факт что большинство тормозов юзерленда из-за универсального
> интерфейса сокетов.  весь (часть) TCP/IP стек(а) можно вынести в юзерланд,
> выкинув весь software intrrupt процессинг.  в тун запихнуть можно тем же
> bpf'ом.

Что такое software intrrupt?

> опять же pf это фактически до -100Mbit/s.  в частности из-за "scrub in".
Если "без", то можно получить больше?

>> > ЗЫЖ ещё бы SMP продвигалось, было б совсем интересно. Кстати, что там
>> > слышно "в кругах", конкурирующая SMPng оно к опёнку никак не это...?
>> > Ну хотяб в плане источника идей и примеров реализации.
> SMPng это из фри?  Никак не помогает.
> А так надо много чего чинить, даже если хочется чтобы базовые spl'и
> превратились в мутексы.

Да, из фри... В общем описании: http://www.freebsd.org/smp/index.html,
и завязанная на неё сетевая часть
http://www.freebsd.org/projects/netperf/index.html.
Вообще тема в том, чтобы "...Important steps along the way included
redesigning significant portions of the FreeBSD kernel architecture
around the notion of ubiquitous parallelism: that at any moment, many
processors might enter the kernel at the same time...". Как я понял -
чтобы разные части кернела могли одновременно исполняться параллельно
на нескольких процессорах.
В противовес тому, что с GiantLock'ом, где только один кернел-тред и
только на одном ядре проца исполняется.
Вроде так, если я ничо не наврал.

А как в опене? Я вообще не пойму как эту тему понять кроме чтения кода
кернела. Но читать код кернела мне трудно даже если заранее известно
чем занимается читаемый фрагмент :-)). То бишь понять "как у нас
устроены прерывания и вообще основные черты SMP" из кода не могу.
Моё понимание SMP в опене остановилось на том, что кернел садится на
первое ядро проца, а если есть ещё ядра, то кернел на них крутит
юзерспейсовые процессы.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: как зажат

Alexander Yurchenko-3
On Thu, Feb 12, 2009 at 04:55:45PM +0500, engineer wrote:
> > известный факт что большинство тормозов юзерленда из-за универсального
> > интерфейса сокетов.  весь (часть) TCP/IP стек(а) можно вынести в юзерланд,
> > выкинув весь software intrrupt процессинг.  в тун запихнуть можно тем же
> > bpf'ом.
>
> Что такое software intrrupt?

Когда приходит прерывание от сетевой карты (hardware interrupt), драйвер
вынимает из нее кадр. Но обработать его, то есть пропарсить все
заголовки, выделить tcp сегмент и т.д. он не может, как как это дело
долгое, возможно связанное с выделением памяти, и поэтому не может
происходить в контексте аппаратного прерывания.

Вместо этого драйвер генерирует так называемое "программное" прерывание
(software interrupt), например ставит некий флажок в ядре, вы завершает
обработку аппаратного прерывания. Программное прерывание затем будет
обработано например по выходу из какого-нибудь системного вызова или при
переключении процессов. И уже обработчик этого прерывания будет делать
обработку пакета.

Проблема при таком подходе - это неконтролируемые задержки в обработке
входящих пакетов и лишняя трата времени.

> А как в опене? Я вообще не пойму как эту тему понять кроме чтения кода
> кернела. Но читать код кернела мне трудно даже если заранее известно
> чем занимается читаемый фрагмент :-)). То бишь понять "как у нас
> устроены прерывания и вообще основные черты SMP" из кода не могу.
> Моё понимание SMP в опене остановилось на том, что кернел садится на
> первое ядро проца, а если есть ещё ядра, то кернел на них крутит
> юзерспейсовые процессы.

Не совсем. Когда ядро работает на каком-то процессоре, на всех других
процессорах ядро работать не может.

> --
> engineer

--
   Alexander Yurchenko


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: как зажат

Anton Maksimenkov-2
>> Моё понимание SMP в опене остановилось на том, что кернел садится на
>> первое ядро проца, а если есть ещё ядра, то кернел на них крутит
>> юзерспейсовые процессы.
>
> Не совсем. Когда ядро работает на каком-то процессоре, на всех других
> процессорах ядро работать не может.

Так. Я может неправильно выразился, и не "кернел крутит на них
юзерские процессы", а... кернел запускает юзерский процесс Х на
соседнем (не своём то есть) ядре процессора?
Как бы это сказать-то,... хочу понять как собственно кернел
эксплуатирует, использует, много процессоров. И почему в текущем виде
ни в опене ни, как я понимаю, во фре невозможно какую-то часть кернела
крутить на другом(их) ядре процессора.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: как зажат

Dinar Talypov
On Thu, 12 Feb 2009 16:11:23 +0300
engineer <[hidden email]> wrote:

> >> Моё понимание SMP в опене остановилось на том, что кернел садится на
> >> первое ядро проца, а если есть ещё ядра, то кернел на них крутит
> >> юзерспейсовые процессы.
> >
> > Не совсем. Когда ядро работает на каком-то процессоре, на всех других
> > процессорах ядро работать не может.
>
> Так. Я может неправильно выразился, и не "кернел крутит на них
> юзерские процессы", а... кернел запускает юзерский процесс Х на
> соседнем (не своём то есть) ядре процессора?
> Как бы это сказать-то,... хочу понять как собственно кернел
> эксплуатирует, использует, много процессоров. И почему в текущем виде
> ни в опене ни, как я понимаю, во фре невозможно какую-то часть кернела
> крутить на другом(их) ядре процессора.

кернел разделен на две части верхний(top) и нижний(bottom)(судя по книжке 4.4BSD Design and Implementation)
так вот в нижней части крутится все железо, т.е. с сетевой карточки пришедший фрейм изымается в mbuf, при этом просходит hardware interrupt, а далее просто подымается наверх, ставится в очередь, которая обслуживается по software interrupt.
То есть можно сказать кернел напоминает часы с шестернями, где каждая шестеренка(драйвер и т.д.) обрабатывает определенную задачу. Причем обработка задач унифицирована и идет по очередям.

Многозадачность в данном виде прдставляет собой просто тупую очередность исполнения задач за определенное время.
Поэтому и получаются задержки.

Кернел можно крутить на различных ядрах, при условии что будут точно определенные блокировки, которые позволяют избежать deadlock'ов, зачастую реализация таких блокировок очень сложна и не дает желаемого эффекта.



 


--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: как зажат

Alexander Yurchenko-3
In reply to this post by Anton Maksimenkov-2
On Thu, Feb 12, 2009 at 04:11:23PM +0300, engineer wrote:

> > Не совсем. Когда ядро работает на каком-то процессоре, на всех других
> > процессорах ядро работать не может.
>
> Так. Я может неправильно выразился, и не "кернел крутит на них
> юзерские процессы", а... кернел запускает юзерский процесс Х на
> соседнем (не своём то есть) ядре процессора?
> Как бы это сказать-то,... хочу понять как собственно кернел
> эксплуатирует, использует, много процессоров. И почему в текущем виде
> ни в опене ни, как я понимаю, во фре невозможно какую-то часть кернела
> крутить на другом(их) ядре процессора.

Чтобы запустился ядерный код, нужно либо прерывание, либо исключение. В
обоих случаях перед входом в обработчик ядро пытается захватить
глобальный лок. Если он уже захвачен (работает обработчик на другом
процессоре), данный процессор начинает греть царствие небесное, крутясь в
спинлоке. Когда обработка прерывания или исключения на другом процессоре
закончилась, наш процессор начинает исполнять ядерный код. Таким образом
в данный момент времени только один процессор может исполнять код ядра.
Все остальные могут исполнять или пользовательские инструкции, или
висеть в спинлоках, ожидая свою очередь войти в ядро.

> --
> engineer

--
   Alexander Yurchenko


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: как з

Mike Belopuhov
In reply to this post by Anton Maksimenkov-2
On Thu, Feb 12, 2009 at 16:55 +0500, engineer wrote:

> >> > И ещё. Если так, то это ж получается опять из ядра в юзерспейс и
> >> > обратно гонять весь поток. Получим опять что машинка от силы единицы
> >> > мегабит пережует...
> >
> > известный факт что большинство тормозов юзерленда из-за универсального
> > интерфейса сокетов.  весь (часть) TCP/IP стек(а) можно вынести в юзерланд,
> > выкинув весь software intrrupt процессинг.  в тун запихнуть можно тем же
> > bpf'ом.
>
> Что такое software intrrupt?
>

это "софтверный интеррупт", который вызывается не железом, но исполняется
в interrupt контексте а не в контексте какого-либо процесса.  типичный
пример - ipintr (погрепай на предмет NETISR).  можешь у клавдии почитать:

http://www.openbsd.org/papers/asiabsdcon08-network.pdf
http://www.openbsd.org/papers/asiabsdcon08-network

или в том же Design and Implementation of 4.4BSD Operating System.

> > опять же pf это фактически до -100Mbit/s.  в частности из-за "scrub in".
> Если "без", то можно получить больше?
>

разумеется.

> >> > ЗЫЖ ещё бы SMP продвигалось, было б совсем интересно. Кстати, что там
> >> > слышно "в кругах", конкурирующая SMPng оно к опёнку никак не это...?
> >> > Ну хотяб в плане источника идей и примеров реализации.
> > SMPng это из фри?  Никак не помогает.
> > А так надо много чего чинить, даже если хочется чтобы базовые spl'и
> > превратились в мутексы.
>
> Да, из фри... В общем описании: http://www.freebsd.org/smp/index.html,
> и завязанная на неё сетевая часть
> http://www.freebsd.org/projects/netperf/index.html.
> Вообще тема в том, чтобы "...Important steps along the way included
> redesigning significant portions of the FreeBSD kernel architecture
> around the notion of ubiquitous parallelism: that at any moment, many
> processors might enter the kernel at the same time...". Как я понял -
> чтобы разные части кернела могли одновременно исполняться параллельно
> на нескольких процессорах.
> В противовес тому, что с GiantLock'ом, где только один кернел-тред и
> только на одном ядре проца исполняется.
> Вроде так, если я ничо не наврал.
>

ну так и что? как это помогает чинить кернель?

> А как в опене? Я вообще не пойму как эту тему понять кроме чтения кода
> кернела. Но читать код кернела мне трудно даже если заранее известно
> чем занимается читаемый фрагмент :-)). То бишь понять "как у нас
> устроены прерывания и вообще основные черты SMP" из кода не могу.
> Моё понимание SMP в опене остановилось на том, что кернел садится на
> первое ядро проца, а если есть ещё ядра, то кернел на них крутит
> юзерспейсовые процессы.

ну это частично неправльное понимание.  кернел исполняется на всех
процессах в S(!)MP системе (на то она и симметричная).  бутится кернель
на бутовом проце, дальше, обнаружив (из MPBIOS таблиц или из ACPI),
что присутствуют еще процы он их "запускает", инсталлируя для каждого
по MP трамполину и посылая серию IPI (то бишь InterProcessor Interrupt).
каждый Application CPU начинает исполнение кернела грубо говоря с
функции main.

для чего всё то. а для того чтобы процесс, исполняющийся на цпу1 и
захотевший сделать сисколл (read например) залез в кернель на том
же цпу1.

теперь про локинг.  на UP машинах весь локинг реализуется с помощью
маскирования прерываний (SPL, Set Interrupt Priority), таким образом
сделав splnet() мы застраховали себя от возможности быть прерванным
любым другим прерыванием с уровнем IPL_NET и ниже (см. spl(9)).
на MP машинах у каждого цпу есть своя маска прерываний и посему
такой метод уже не достаточен, поэтому в MP системах нужны два типа
блокировок: CPU exclusion lock и process exclusion lock.  первый
тип локов ограничивает конкурентный доступ к ресурсу между несколькими
CPU и в OpenBSD реализован как spinning mutex(9).  Разграничение
между доступом к ресурсу, раздиляемому только процессами реализовано
спящим (при желании) локом rwlock(9), поскольку спать можно только
в контексте процесса.

про прерывания.  прерывания в MP системах на i386 и amd64 приходят
на устройство I/O APIC, реализованном в системном чипсете, тогда как
маска IRQ находится непосредственно в CPU (LAPIC, Local Advanced
Programmable Interrupt Controller).  все цпя сидят на одной шине
с I/O APICами (их может быть несколько) и прерываются в зависимости
от своей маски.  в OpenBSD прерывания обрабатываются только на
boot процессоре.

биглок (он же kernel_lock) разграничивает доступ к ядру для всех
процессов и прерваний, происходящих в системе.  он берется
автоматически при каждом входе процесса в ядро (сисколл, трап) и
при каждом прерывании, тем самым предотвращая все возможные гонки
за ресурсы ядра.  отдать его можно явно вызвав KERNEL_PROC_UNLOCK
в контексте процесса.

если процесс зашел в кернел по сисколу, взял биглок и работает
с уровнем IPL_NONE, ничто не мешает прийти прерыванию, прервать
процесс, поднять IPL до заданного уровня, рекурсивно взять
kernel_lock выполнится, отдать biglock, вернуть управление
процессу.

при контексном переключении биглок отдается, процесс помечается
как P_BIGLOCK и при следующем переключении на него, биглок будет
возвращен.

существует также еще один рекурсивный лок -- sched_lock,
предохраняющий данные скедулера, всегда используется с
уровнем IPL_SCHED (соотв. IPL_HIGH).

при работе с локами важно соблюдать порядок взятия и отдачи
локов:

- правильно:

        lock_enter(1);
        lock_leave(1);
        lock_enter(2);
        lock_leave(2);

- правильно:

        lock_enter(1);
        lock_enter(2);
        lock_leave(2);
        lock_leave(1);

- НЕправильно:

        lock_enter(1);
        lock_enter(2);
        lock_leave(1);
        lock_leave(2);

P.S. на прошлом опенкиеве рассказывал такое:
http://crypt.org.ru/~mkb/pub/talks/openkyiv2008.pdf

> --
> engineer