LINUX.ORG.RU

Поделюсь своими впечатлениями:

- не быстрый, context swicth'ы через user-space. Ждем kdbus.

- нет хорошего чистого C-клиента. Есть хорошая реализация в systemd, но только 211 кажется.

placement_new ★★
()
Последнее исправление: placement_new (всего исправлений: 2)

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

Сколько процессов? Если два - то оно точно не нужно.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Вангую что будет затык с кроссплатформой.

В этом проекте не нужно.

Сколько процессов? Если два - то оно точно не нужно.

От 2-х до 10-ти.

UVV ★★★★★
() автор топика

Если тебе не нужно гонять через него мегабайты payload'а (или, как вариант, посылать тысячи сообщений в секунду) — юзай dbus, незачем городить свой велосипед. Если твой интерфейс ложится на объектную модель — тем более.

Если всё же нужно первое — то или жди kdbus, или перебрасывайся fd на шаренную память. Если нужно второе — то или жди kdbus, или юзай unix-сокеты.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)

Наличие демона, проблемы со скоростью и, иногда, со стабильностью, наркоманский API. Возьми лучше ZMQ.

hateyoufeel ★★★★★
()
Ответ на: комментарий от placement_new

- не быстрый, context swicth'ы через user-space. Ждем kdbus.

Как уже выяснили в lkml, проблемы с производительностью d-bus являются следствием кривого кода самого демона d-bus.

hateyoufeel ★★★★★
()
Ответ на: комментарий от intelfx

Я даже приведу тебе ссылку: https://lkml.org/lkml/2015/4/27/740

Если тебе лень читать, то вот тебе выдержка:

Quite frankly, the whole "kdbus is important for performance" seems to
be *totally* invalidated by even a minimal look at profiles for that
thing. Here's the top-15 offender list:

   2.62%  gdbus    libc-2.20.so                [.] _int_malloc
   2.43%  gdbus    libc-2.20.so                [.] free
   2.31%  server   libc-2.20.so                [.] free
   2.12%  gdbus    libc-2.20.so                [.] malloc
   1.77%  gdbus    libglib-2.0.so.0.4200.2     [.] g_utf8_validate
   1.43%  gdbus    libglib-2.0.so.0.4200.2     [.] g_slice_alloc
   1.41%  gdbus    libglib-2.0.so.0.4200.2     [.] g_hash_table_lookup
   1.28%  server   libc-2.20.so                [.] _int_malloc
   1.27%  gdbus    libglib-2.0.so.0.4200.2     [.] g_mutex_lock
   1.22%  gdbus    libglib-2.0.so.0.4200.2     [.] g_variant_unref
   1.16%  server   libc-2.20.so                [.] malloc
   1.14%  gdbus    libglib-2.0.so.0.4200.2     [.] g_bit_lock
   1.07%  gdbus    libglib-2.0.so.0.4200.2     [.] g_slice_free1
   1.05%  gdbus    libglib-2.0.so.0.4200.2     [.] g_bit_unlock
   1.01%  gdbus    libglib-2.0.so.0.4200.2     [.] g_mutex_unlock

there's not a kernel function in sight in the top-15, and it's all
just overhead. The above is from the server side, but the client looks
similar.

If somebody wants to speed up dbus, they should likely look at the
user-space code, not the kernel side.

И пожалуйста, больше не ной тут про производительность kdbus.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

И вот о чём этот тест говорит? Почему он уверен, что этой хрени можно избежать, оставаясь в рамках юзерспейса?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Потому что он не видит здесь ядерных функций. А значит мы упираемся не в ядро. А раз мы упираемся не в ядро, есть пространство для оптимизаций.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Конечно, мы не упираемся в ядро. В юзерспейсной-то реализации. Которой от ядра только сокеты нужны.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Конечно, мы не упираемся в ядро. В юзерспейсной-то реализации. Которой от ядра только сокеты нужны.

Ты вот это сейчас серьезно?

kirk_johnson ★☆
()
Ответ на: комментарий от intelfx

Не с той стороны на проблему смотришь. Зачем извращаться и тащить в ядро новые структуры данных и функции, когда то же самое можно сделать в userspace.

kirk_johnson ★☆
()
Ответ на: комментарий от intelfx

Я думаю, что я больше верю старому жирному шведу, который последние 25 лет занимается разработкой операционных систем, чем 19-летнему студиозу с ЛОРа. Тем более, что старый жирный швед приводит вполне убедительные аргументы.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

А мне-то зачем верить? Я никаких аргументов не привожу, только высказываю сомнения в валидности уже приведённых.

intelfx ★★★★★
()
Ответ на: комментарий от kirk_johnson

Откуда уверенность в том, что дбас лажает просто потому что криво написан, а не потому что нельзя по-другому (не перетаскивая сервер в ядро)?

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Откуда уверенность в том, что дбас лажает просто потому что криво написан, а не потому что нельзя по-другому (не перетаскивая сервер в ядро)?

Потому что есть примеры шин, которые не лажают.

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

В конечном итоге даже HTTP сервер упрется в проблемы юзерспейсности. HTTP сервер в ядре уже был. Не надо такое повторять.

kirk_johnson ★☆
()
Ответ на: комментарий от intelfx

У тебя самого же в профиле написано.

«You cite no new arguments to a previously well-debated issue. Just saying that you are wrong is, therefore, a sufficient response.» — Samium Gromoff

Проблема производительности dbus хорошо исследована гораздо более квалифицированными людьми чем ты. Так что упс.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Я не могу быть «wrong» или «right», у меня здесь нет своей точки зрения.

intelfx ★★★★★
()
Ответ на: комментарий от kirk_johnson

Потому что есть примеры шин, которые не лажают.

И эти шины, которые не лажают, достаточно похожи на dbus, чтобы можно было утверждать, что проблема в качестве кода dbus-сервера, а не в том, что семантику dbus нельзя реализовать по-другому?

HTTP сервер в ядре уже был.

Ты сравниваешь HTTP-сервер с IPC. К последнему чуть другие требования. Early/late boot какой-нибудь. Ты же первый будешь кидаться дерьмом, если этот dbus-ng включат в состав systemd как обязательный компонент.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

О майн гот! Фаерфокс ещё не в ядре! Поэтому он так тормозит!

anonymous
()
Ответ на: комментарий от kirk_johnson

HTTP сервер в ядре уже был

Нефиг так пугать. Википедия говорит, что это был отдельный прожект

anonymous
()
Ответ на: комментарий от intelfx

И эти шины, которые не лажают, достаточно похожи на dbus, чтобы можно было утверждать, что проблема в качестве кода dbus-сервера, а не в том, что семантику dbus нельзя реализовать по-другому?

Эти шины выполняют ту же задачу, но лучше. Значит можно написать лучше. А значит, в ядро тащить не нужно. Что тебе в этой простой и банальной логике непонятно?

Ты сравниваешь HTTP-сервер с IPC. К последнему чуть другие требования. Early/late boot какой-нибудь. Ты же первый будешь кидаться дерьмом, если этот dbus-ng включат в состав systemd как обязательный компонент.

Зачем IPC в early boot? ЗАЧЕМ?! В initrd я хочу видеть немного софта, который просто подгрузит мне /. ЗАЧЕМ МНЕ ТАМ IPC, НАРКОМАН ТЫ ЭДАКИЙ?

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Эти шины выполняют ту же задачу, но лучше.

Ту же задачу? Прямо как дбас, с той же или похожей семантикой, с мультикастом и прочими фичами? Названия в студию.

Значит можно написать лучше. А значит, в ядро тащить не нужно.

1 ↛ 2

Зачем IPC в early boot? ЗАЧЕМ?! В initrd я хочу видеть немного софта, который просто подгрузит мне /. ЗАЧЕМ МНЕ ТАМ IPC, НАРКОМАН ТЫ ЭДАКИЙ?

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

Как мило. И какое же понятие я некорректно употребил?

// анонимусу, как всегда, известен только один тип аргумента — к личности...

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

Да, это очень даже универсальное и кросс-платформенное средство, не считая сам догадаешься чего.

nikolnik ★★★
()

можешь еще просто посмотреть, сколько и какие программы используют D-Bus. при желании можешь спросить потом у самих авторов, почему выбрали именно его.

Мне в контексте Qt

в кутях D-Bus вообще «изкаробки», а к чему-то другому, вероятно, придется самому еще городить обертку.

CryAngel
()
Ответ на: комментарий от intelfx

Ту же задачу? Прямо как дбас, с той же или похожей семантикой, с мультикастом и прочими фичами? Названия в студию.

Причем тут семантика? Почему ты так в это уперся? Проблема dbus не в семантике, а в тормозной обработке сообщений. Тот же zero- или nano- mq работают быстрее. А если к zeromq прикрутить диспетчера, то ВНЕЗАПНО, получается dbus.

Значит можно написать лучше. А значит, в ядро тащить не нужно.

1 ↛ 2

Есть такое замечательное правило: если что-то можно не тащить в ядро, это в ядро тащить не нужно. Так что нет, ещё как следует. Это я тебе как человек пишущий ядро заявляю.

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

Я тебя считаю наркоманом. Твоя initrd не должна заниматься такими вещами, иначе станет слишком сложной. То что ты тут пытаешься представить уже больше похоже на тонкого клиента.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Причем тут семантика? Почему ты так в это уперся?

Потому что если прикрутить диспетчера, прикрутить ACL, прикрутить метаданные, прикрутить мультикаст и так далее, то «работает быстрее» имеет все шансы стать «работает так же» или «работает медленнее». И только предъявив реализацию, делающую ровно то же самое, но лучше (или явно указав на косяк в существующем коде, что эквивалентно), можно говорить о том, что «код говно».

Есть такое замечательное правило: если что-то можно не тащить в ядро, это в ядро тащить не нужно.

С этим я совершенно согласен. Осталось доказать, что и вправду можно не тащить.

Твоя initrd не должна заниматься такими вещами, иначе станет слишком сложной.

А вот это уже не тебе решать, чем она должна заниматься, а чем — нет. :]

initramfs занимается тем, что монтирует корень, со всеми вытекающими отсюда вещами. И если система построена так, что внезапно ребутнувшаяся машина пинает меня по мылу и ждёт, пока я в неё ssh-нусь и введу пассфразу для доступа к диску, значит, в initramfs окажутся networkd и ssh. Ну и так далее.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Потому что если прикрутить диспетчера, прикрутить ACL, прикрутить метаданные, прикрутить мультикаст и так далее, то «работает быстрее» имеет все шансы стать «работает так же» или «работает медленнее». И только предъявив реализацию, делающую ровно то же самое, но лучше (или явно указав на косяк в существующем коде, что эквивалентно), можно говорить о том, что «код говно».

О господи... zeromq умеет мультикаст, умеет метаданные и диспетчера крутить не надо, он там тоже реализуется в два клика. Серьезно, чувак, оглянись уже по сторонам. На dbus жизнь не заканчивается.

С этим я совершенно согласен. Осталось доказать, что и вправду можно не тащить.

Нет, осталось доказать, что нужно тащить. Говорю же, ты не с того ракурса смотришь на проблему.

А вот это уже не тебе решать, чем она должна заниматься, а чем — нет. :]

Ммм... Вообще-то мне. Я же администрирую сервер.

initramfs занимается тем, что монтирует корень, со всеми вытекающими отсюда вещами. И если система построена так, что внезапно ребутнувшаяся машина пинает меня по мылу и ждёт, пока я в неё ssh-нусь и введу пассфразу для доступа к диску, значит, в initramfs окажутся networkd и ssh. Ну и так далее.

Ты опять не с той стороны на проблему смотришь. Сперва придумай сценарий, когда тебе нужно шифровать какие-то данные, которые лежат на руте, а не в /var/lib/secret-data, а потом уже засовывай networkd в initramfs.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Нет, осталось доказать, что нужно тащить. Говорю же, ты не с того ракурса смотришь на проблему.

Раскрою: с чего ты взял, что описанные тобой проверки ACL и прочее работают в kernelspace быстрее, чем в userspace?

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

О господи... zeromq умеет мультикаст, умеет метаданные и диспетчера крутить не надо, он там тоже реализуется в два клика.

Всё-то он умеет, только это не то же самое, что дбас.

http://lists.freedesktop.org/archives/dbus/2010-August/013214.html

Твоя initrd не должна заниматься такими вещами, иначе станет слишком сложной.

А вот это уже не тебе решать, чем она должна заниматься, а чем — нет. :]

Ммм... Вообще-то мне. Я же администрирую сервер.

Ты администрируешь мой сервер? Хм, а я и не знал. Спасибо, чувак.

Сперва придумай сценарий, когда тебе нужно шифровать какие-то данные, которые лежат на руте, а не в /var/lib/secret-data

Корень на сетевой ФС. Сервер во внутренней защищённой сети.

intelfx ★★★★★
()
Ответ на: комментарий от kirk_johnson

Ну вот я допускаю такой вариант (почему бы и не быть им быстрее?). А ты не допускаешь. Поэтому доказываешь ты.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Всё-то он умеет, только это не то же самое, что дбас.

А никто и не говорил, что то же самое. А вот узкие места dbus в нем почему-то реализованы лучше. Может всё-таки сперва переписать dbus в userspace используя код из zeromq, а потом уже пытаться присунуть страшного монстра в ядро, мм?

Корень на сетевой ФС. Сервер во внутренней защищённой сети.

И чо?

kirk_johnson ★☆
()
Ответ на: комментарий от intelfx

Ну вот я допускаю такой вариант (почему бы и не быть им быстрее?). А ты не допускаешь. Поэтому доказываешь ты.

Нет, это работает немного не так. Ты (и другие фанбои kdbus) считаете, что они почему-то должны быть быстрее. А Линус и Энди — что переписать dbus выглядит более разумной идеей. В итоге kdbus в ядро не взяли.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

А вот узкие места dbus в нем почему-то реализованы лучше.

Может быть, узкие места dbus-сервера там возникли из сущности самого протокола (i. e. нельзя по-другому), а не вследствие технической кривости кода?

переписать dbus в userspace используя код из zeromq

А кто сказал, что код из zeromq вообще применим к той модели, которую реализует dbus? Ты ещё предложи код из binder'а использовать.

И чо?

А машинка снаружи. Ей авторизоваться нужно.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Может быть, узкие места dbus-сервера там возникли из сущности самого протокола (i. e. нельзя по-другому), а не вследствие технической кривости кода?

Может быть :) Но пока что top-15 это обработка utf8. Что-то мне подсказывает, что можно сделать быстрее :D

А кто сказал, что код из zeromq вообще применим к той модели, которую реализует dbus? Ты ещё предложи код из binder'а использовать.

Код передачи данных? Я думаю, он применим ко всем сущностям, которым данные передавать нужно.

А машинка снаружи. Ей авторизоваться нужно.

Если машин много, у тебя явно есть сервер с VPN, и задача авторизации лежит на нем. Если машинка одна, то я не вижу смысла делать рут по сети, достаточно подцепить нужные данные, для чего в руте уже будет VPN.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Ты (и другие фанбои kdbus)

Это можно считать исчерпанием технических аргументов и началом перехода на личности? Окей. Ты <insert-your-favorite-expletive>. По-моему, равноценный ответ.

считаете, что они почему-то должны быть быстрее

Да они и есть быстрее. Быстрее, чем то, что уже написано. Чтобы говорить что-то дальше, нужно предоставить обоснование. Например: «если пофиксить dbus-daemon вот так, он станет настолько же быстрым, как и то дерьмо, которые вы пытаетесь смерджить».

А Линус и Энди — что переписать dbus выглядит более разумной идеей. В итоге kdbus в ядро не взяли.

Понятно, что Линус и Энди не будут копаться в юзерспейсном коде, а просто скажут «идите лесом». Они (точнее, первый из них) имеют полное право на это «идите лесом», ибо мейнтейнеры, но вообще-то это остаётся их личным мнением.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Да они и есть быстрее. Быстрее, чем то, что уже написано. Чтобы говорить что-то дальше, нужно предоставить обоснование. Например: «если пофиксить dbus-daemon вот так, он станет настолько же быстрым, как и то дерьмо, которые вы пытаетесь смерджить».

О господи... Чтобы засунуть код в ядро, нужно представить техническое обоснование, ПОЧЕМУ ОН ТАМ НЕОБХОДИМ. Понимаешь? Не ядерные разрабы должны за Грега бенчмарки делать, а Грег должен сказать «так-то и так-то, уперлись в ядро, делать нечего». Пока что ядерные разрабы сделали бенчмарки и выяснили, что в ядро не уперлись. И значит аргумент «мы уперлись в ядро» не канает. Ты правда этого не понимаешь?

kirk_johnson ★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.