SMP

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

SMP

irix

Hello Openbsd,

  Как  вы  считаете  когда опёночники начнут серьёзно пилить SMP чтобы
  ядро  паралелилось  и  перпендикулярилось  на все процы и ядра и всё
  работало  в вногопоточке включая I/O с IP стеком и прочее ? А то уже
  все сделали, а опёночники чтото не телятся.

--
Best regards,
 irix                          mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Alexander Yurchenko-3
3 ноября 2010 г. 0:18 пользователь irix <[hidden email]> написал:
>
> Hello Openbsd,
>
>  Как  вы  считаете  когда опёночники начнут серьёзно пилить SMP чтобы
>  ядро  паралелилось  и  перпендикулярилось  на все процы и ядра и всё
>  работало  в вногопоточке включая I/O с IP стеком и прочее ? А то уже
>  все сделали, а опёночники чтото не телятся.

Да зачем пилить костыли. Надо взять микроядро, например L4, и поверх
него запустить несколько копий OpenBSD, по числу ядер.

>
> --
> Best regards,
>  irix                          mailto:[hidden email]
>
>



--
Alexander Yurchenko
Reply | Threaded
Open this post in threaded view
|

Re: SMP

Stanislav Kruchinin
In reply to this post by irix

On 03.11.2010 0:18, irix wrote:
>   Как  вы  считаете  когда опёночники начнут серьёзно пилить SMP чтобы
>   ядро  паралелилось  и  перпендикулярилось  на все процы и ядра и всё
>   работало  в вногопоточке включая I/O с IP стеком и прочее ? А то уже
>   все сделали, а опёночники чтото не телятся.
>

Я думаю, никогда, поскольку коммерческие организации не заинтересованы в оплате
этой работы. А бесплатно переписывать пол-ядра никто не будет. Кроме того, в
плане устранения глобальных блокировок в Linux и во FreeBSD сделано не все.
Наиболее нужные вещи, вроде I/O и обработки нижних половин прерываний там,
конечно, уже распараллелены. Но тот же dummynet или pf/ALTQ, к примеру, до сих
пор реализованы в виде одного треда.

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Anton Maksimenkov-2
In reply to this post by irix
3 ноября 2010 г. 2:18 пользователь irix <[hidden email]> написал:
>  чтобы ядро  паралелилось  и  перпендикулярилось
эта пять!

А если серьёзно, то например подсистема scsi была серьёзно переделана.
И как я понимаю почти всё (или всё?) там теперь на мутексах, а не на
spl'ях. Можно сказать "готова к распараллеливанию". Или правильнее -
готова к тестированию и переходу на параллель. Но это одна из самых
"медленных" подсистем (ну, я имею в виду скорость работы дисковой
подсистемы в сравнении например с памятью), так что даже если
гипотетически прям сейчас включить её в параллель, то это оччень мало
скажется на производительности. Если вообще скажется, при
современных-то мощностях процессоров.
Кое чего в UVM'е (подсистема памяти) было заведено на мутексы, так что
какие-то части уже готовы к тому чтобы параллельно работать.
Перевести сетевой стек на параллель пока потуг не видел.

Хотя вообще-то, насколько я могу судить с чужих слов, пока есть
нерешённые проблемы с тем чтобы ядро могло исполнять прерывания на
любых процах (а не только на boot cpu), и это не даёт "включить
распараллеливание" сейчас.

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

> Как  вы  считаете  когда опёночники начнут серьёзно пилить SMP
Не желаете ли подключиться к делу дабы приблизить сроки?

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

Re: SMP

irix
In reply to this post by Stanislav Kruchinin

Hello Stanislav,

Wednesday, November 3, 2010, 12:57:53 AM, you wrote:


SK> On 03.11.2010 0:18, irix wrote:
>>   Как  вы  считаете  когда опёночники начнут серьёзно пилить SMP чтобы
>>   ядро  паралелилось  и  перпендикулярилось  на все процы и ядра и всё
>>   работало  в вногопоточке включая I/O с IP стеком и прочее ? А то уже
>>   все сделали, а опёночники чтото не телятся.
>>

SK> Я думаю, никогда, поскольку коммерческие организации не заинтересованы в оплате
SK> этой работы. А бесплатно переписывать пол-ядра никто не будет. Кроме того, в
SK> плане устранения глобальных блокировок в Linux и во FreeBSD сделано не все.
SK> Наиболее нужные вещи, вроде I/O и обработки нижних половин прерываний там,
SK> конечно, уже распараллелены. Но тот же dummynet или pf/ALTQ, к примеру, до сих
SK> пор реализованы в виде одного треда.

Если  мне  не  изменяет память то в ipfw v3 и новом дупельнете паралель
уже  запустили.  Видел ещё графики тестирования паралельности на пятой
нэтки  в  сравнении  с  линуксом  и  фрёй  на  базе данных, там судя по
графикам  она  их уделала :) Интересно из-за чего, что там есть такого
чего не сделали в линуксе и фре (наверно распаралелили паралель).





--
Best regards,
 irix                            mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Dinar Talypov

В Wed, 3 Nov 2010 09:32:32 +0200
irix <[hidden email]> пишет:

>
> Hello Stanislav,
>
> Wednesday, November 3, 2010, 12:57:53 AM, you wrote:
>

> Если  мне  не  изменяет память то в ipfw v3 и новом дупельнете
> паралель уже  запустили.  Видел ещё графики тестирования
> паралельности на пятой нэтки  в  сравнении  с  линуксом  и  фрёй  на
> базе данных, там судя по графикам  она  их уделала :) Интересно из-за
> чего, что там есть такого чего не сделали в линуксе и фре (наверно
> распаралелили паралель).
>
Открою вам секрет паралель не всегда есть прирост производительности,
а может и наоборот.

Похоже производители процессоров снова смотрят в сторону
однопроцессорности.

--
Dinar Talypov

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Stanislav Kruchinin

On 03.11.2010 9:47, Dinar Talypov wrote:
> Открою вам секрет паралель не всегда есть прирост производительности, а
> может и наоборот.

Из простых оценок ясно, что рост производительности будет линейным только в
идеальном случае: http://ru.wikipedia.org/wiki/Закон_Амдала

>
> Похоже производители процессоров снова смотрят в сторону однопроцессорности.

Имеется в виду x86 или какая-то другая архитектура? Intel уже во времена P4
столкнулась с ограничениями по росту частоты. Как им наращивать
производительность, если не за счет увеличения числа ядер? А многоядерные
процессоры есть в том числе и у ARM, так что SMP сейчас уже есть и в мобильных
устройствах.

> Да зачем пилить костыли. Надо взять микроядро, например L4, и поверх него
> запустить несколько копий OpenBSD, по числу ядер.

Ну предположим, что мы запустили поверх микроядра несколько экземпляров OpenBSD.
Будет очень весело админить несколько копий pf с несколькими конфигами вместо
одного. Но что делать, например, с файл-сервером? Здесь мы сталкиваемся с
другими проблемами: тормозное i/o и отсутствие поддержки нормальных файловых
систем. Теоретически, можно взять реализацию zfs из FreeBSD.

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Dinar Talypov

On Wed, 03 Nov 2010 14:52:49 +0300
Stanislav Kruchinin <[hidden email]> wrote:

>
> On 03.11.2010 9:47, Dinar Talypov wrote:
> > Открою вам секрет паралель не всегда есть прирост
> > производительности, а может и наоборот.
>
> Из простых оценок ясно, что рост производительности будет линейным
> только в идеальном случае: http://ru.wikipedia.org/wiki/Закон_Амдала
>
> >
> > Похоже производители процессоров снова смотрят в сторону
> > однопроцессорности.
>
> Имеется в виду x86 или какая-то другая архитектура? Intel уже во
> времена P4 столкнулась с ограничениями по росту частоты. Как им
> наращивать производительность, если не за счет увеличения числа ядер?
> А многоядерные процессоры есть в том числе и у ARM, так что SMP
> сейчас уже есть и в мобильных устройствах.
>
Вот именно многоядерность, т.е. какая та часть архитектуры процессора
используется в совместном доступе.

На ум приходит Asymmetric multiprocessing, зря про него подзабыли :)



--
Dinar Talypov

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Stanislav Kruchinin
In reply to this post by Stanislav Kruchinin

Кстати, почта очень медленно в рассылку доходит (только через полчаса или
больше). Это из-за spamd наверняка.

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Alexander Yurchenko-3
In reply to this post by Stanislav Kruchinin
3 ноября 2010 г. 14:52 пользователь Stanislav Kruchinin
<[hidden email]> написал:
> Ну предположим, что мы запустили поверх микроядра несколько экземпляров OpenBSD.
> Будет очень весело админить несколько копий pf с несколькими конфигами вместо
> одного. Но что делать, например, с файл-сервером? Здесь мы сталкиваемся с

Что проще, написать конфиг для pf или сделать быстрый и безглючный
fine graned locking?

> другими проблемами: тормозное i/o и отсутствие поддержки нормальных файловых
> систем. Теоретически, можно взять реализацию zfs из FreeBSD.

SMP тут не при чем.

--
Alexander Yurchenko
Reply | Threaded
Open this post in threaded view
|

Re: SMP

Stanislav Kruchinin
In reply to this post by Dinar Talypov

On 03.11.2010 14:09, Dinar Talypov wrote:
> Вот именно многоядерность, т.е. какая та часть архитектуры процессора
> используется в совместном доступе.

Ядра -- это те же процессоры, но реализованные на одном кристалле. L2-кэш или
доступ к памяти у ядер может быть общими, а может и не быть. На этом основные
различия заканчиваются.

>
> На ум приходит Asymmetric multiprocessing, зря про него подзабыли :)

Ну может и вернутся когда-нибудь, на следующем витке спирали.

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Stanislav Kruchinin
In reply to this post by Alexander Yurchenko-3

On 03.11.2010 15:14, Alexander Yurchenko wrote:
> Что проще, написать конфиг для pf или сделать быстрый и безглючный
> fine graned locking?

Я не о сравнении того, что проще, а о том, что в решении с микроядром тоже есть
свои недостатки. Типичный провайдерский роутер сейчас -- двухпроцессорник с
4-ядерными Xeon'ами (8 процессоров). Если нужно будет поддерживать и
синхронизировать 8 копий pf.conf, никто этим пользоваться не будет. Для решения
этого вопроса придется выносить часть функционала OpenBSD в некий процесс,
который будет распределять между копиями ОС какие-то общие данные, вроде
информации из конфигурационных файлов.

>
>> другими проблемами: тормозное i/o и отсутствие поддержки нормальных файловых
>> систем. Теоретически, можно взять реализацию zfs из FreeBSD.
>
> SMP тут не при чем.
>

Безусловно. Просто напоминаю, что есть и другие не менее фундаментальные
проблемы. Устранение проблемы гигантских блокировок не решит сразу всё.

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Andrey N. Oktyabrski-2
In reply to this post by Alexander Yurchenko-3

On 11/03/10 15:14, Alexander Yurchenko wrote:
> Что проще, написать конфиг для pf или сделать быстрый и безглючный
> fine graned locking?
Смотря сколько раз...

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Dmitry Bogdan-2
In reply to this post by Stanislav Kruchinin

>
> On 03.11.2010 14:09, Dinar Talypov wrote:
>> Вот именно многоядерность, т.е. какая та часть архитектуры процессора
>> используется в совместном доступе.
>
> Ядра -- это те же процессоры, но реализованные на одном кристалле. L2-кэш
> или
> доступ к памяти у ядер может быть общими, а может и не быть. На этом
> основные
> различия заканчиваются.
>
>>
>> На ум приходит Asymmetric multiprocessing, зря про него подзабыли :)
>
> Ну может и вернутся когда-нибудь, на следующем витке спирали.
вообще, развитие происходит в обоих направлениях.
возьмём, к примеру, igb :)
может иметь несколько аппаратных очередей для ввода и вывода, каждое может
обслуживаться отдельным ядром (я имею в виду обработчик прерывания), если
системный софт такое умеет.
кроме этого он умеет кучу ненужного фуфла типа TSO/LRO (которое вроде как
должно снимать работу с ЦПУ), а также полезные шняги типа rx/tx csum
разгрузку, тоже должны как-бе олицетворяют мощь Asymmetric MP
многие производители сетевых устройств делают упор на многопоточную
обработку данных, взять например циckо АSR

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

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Valentin Nechayev

 Thu, Nov 04, 2010 at 16:04:14, dsb wrote about "Re: SMP":

> я кстати сведующим людям вопрос задам другой, поддержка в ядре MSI
> ожидается какая-либо? я только представляю, что это такое, нужна
> собственно поддержка со стороны системного софта?

Если речь про message signaled interrupt - конечно, поддержка нужна, ибо:
1. Нужно разрешить это вообще в устройстве (по умолчанию может быть или вообще
отключено, или обычным прерыванием), а для этого знать, что за зверь
2. Нужно настроить раутинг прерывания на нужный ioAPIC (детали зависят от
чипсета)
3. Нужно настроить в местном ioAPIC трансляцию сообщения в номер прерывания
в таблице (у процессора/ядра будет вызываться уже конкретный intN)


-netch-

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Valentin Nechayev
In reply to this post by Dinar Talypov

 Wed, Nov 03, 2010 at 09:47:27, dinar wrote about "Re: SMP":

> > Если  мне  не  изменяет память то в ipfw v3 и новом дупельнете
> > паралель уже  запустили.  Видел ещё графики тестирования
> > паралельности на пятой нэтки  в  сравнении  с  линуксом  и  фрёй  на
> > базе данных, там судя по графикам  она  их уделала :) Интересно из-за
> > чего, что там есть такого чего не сделали в линуксе и фре (наверно
> > распаралелили паралель).
> >
> Открою вам секрет паралель не всегда есть прирост производительности,
> а может и наоборот.
>
> Похоже производители процессоров снова смотрят в сторону
> однопроцессорности.

Не могу отделаться от мысли, что данное сообщение целиком клонит в
сторону "нафига вам эта SMP? без неё проще и лучше". Общая идея
понятна, но согласиться с ней невозможно.

Для начала, "снова смотрят в сторону однопроцессорности" - если
как-то и смотрят, то только с ностальгией. По крайней мере для x86 в
десктопных, серверных и около того версиях процессоров возврат к
одному ядру уже не будет никогда. Это озвучивалось много раз и
альтернативы данной ситуации не видно. Многоядерность входит даже в
embedded, хотя там далеко не скоро станет основным вариантом. В
основной же области применений для Unix-подобной системы возврат к
одноядерности может быть только в том случае, если произойдёт
глобальный кризис (кончится нефть) и придётся всё делать на коленке
с техпроцессами времён в лучшем случае 90-х. Откуда Вы взяли
утверждение про обратную тенденцию - мне непонятно, это противоречит
всей видимой мне текущей тенденции.

Из этого, вопрос уже года 3 не стоит в стиле "параллелить или не
параллелить", вопрос - как именно это делать. Мы видим множество
решений для userland, и несколько для ядра, но в общем все они
сводятся или к блокировкам и сериализации (традиционный SMP), или к
обмену сообщениями (в userland это решения типа Erlang,
multiprocessing.py или 0mq, в ядре - DragonFlyBSD и частично Solaris).

То, что OpenBSD умеет userland SMP - уже в этом плане существенный
прогресс (и шанс на то, что какое-то развитие таки будет).  Но
дальше можно было бы медленно и постепенно освобождать и ядро от
старых оков. Радикальные решения в стиле FreeBSD5, пожалуй, не
нужны, но двигаться таки надо.

Ну а по поводу "паралель не всегда есть прирост производительности"
- на то она и разработка, чтобы найти пути, когда есть прирост. Что
они есть - доказано всей отраслью.


-netch-

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Alexander Yurchenko-3
In reply to this post by Valentin Nechayev
4 ноября 2010 г. 11:09 пользователь Valentin Nechayev
<[hidden email]> написал:
> Если речь про message signaled interrupt - конечно, поддержка нужна, ибо:
> 1. Нужно разрешить это вообще в устройстве (по умолчанию может быть или вообще
> отключено, или обычным прерыванием), а для этого знать, что за зверь
> 2. Нужно настроить раутинг прерывания на нужный ioAPIC (детали зависят от
> чипсета)
> 3. Нужно настроить в местном ioAPIC трансляцию сообщения в номер прерывания
> в таблице (у процессора/ядра будет вызываться уже конкретный intN)

И только после этого заработают очереди в igb :)

> -netch-

--
Alexander Yurchenko
Reply | Threaded
Open this post in threaded view
|

Re: SMP

Dmitry Bogdan-3

On Thu, 4 Nov 2010 12:20:31 +0300
Alexander Yurchenko <[hidden email]> wrote:

>  ноября 2010 г. 11:09 пользователь Valentin Nechayev
> <[hidden email]> написал:
> > Если речь про message signaled interrupt - конечно, поддержка нужна, ибо:
> > 1. Нужно разрешить это вообще в устройстве (по умолчанию может быть или вообще
> > отключено, или обычным прерыванием), а для этого знать, что за зверь
> > 2. Нужно настроить раутинг прерывания на нужный ioAPIC (детали зависят от
> > чипсета)
> > 3. Нужно настроить в местном ioAPIC трансляцию сообщения в номер прерывания
> > в таблице (у процессора/ядра будет вызываться уже конкретный intN)
>
> И только после этого заработают очереди в igb :)
кстати ещё вопрос - собственно igb собираются приволочь в ядро?

em я так понял заставляет их (новые чипы 76,77 для которых его создали) работать в режиме совместимости.
я тут заказал себе двухголовый одночиповый igb какого-то китайского прозводителя (Femrice кажется), как прилетит - могу поучаствовать в тестировании драйвера если его будут портировать.

Reply | Threaded
Open this post in threaded view
|

Re: SMP

Anton Maksimenkov-2
In reply to this post by Dmitry Bogdan-2
4 ноября 2010 г. 11:04 пользователь Dmitry Bogdan <[hidden email]> написал:
> возьмём, к примеру, igb :)
> может иметь несколько аппаратных очередей для ввода и вывода, каждое может
> обслуживаться отдельным ядром (я имею в виду обработчик прерывания), если
> системный софт такое умеет.

А как оно узнаёт в какую именно очередь совать данный конкретный
пришедший пакет?

> поддержка в ядре MSI ожидается какая-либо?
ИМХО, это пока что далеко не самое "узкое место", так что ещё есть
куда силы/время/мозги потратить...
--
antonvm