LINUX.ORG.RU

Kdbus — межпроцессный обмен сообщениями на уровне ядра

 , ,


0

0

В целях увеличения производительности компьютера представлен проект Kdbus — реализация службы межпроцессного обмена сообщениями dbus на уровне ядра Linux. Производительность заметно возрастает за счёт уменьшения числа копирования областей памяти и минимизации числа переключения контекста между ядром и процессом-демоном, работающим в пользовательском пространстве.

Пока ещё надо запускать службу dbus для аутентификации и активации dbus, драйвер org.freedesktop.DBus пока реализован только через службу dbus.

>>> Подробности

★★

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

Это, конечно, супермегаафигенно. Но не будет ли это попыткой из монолита сделать микроядро?

post-factum ★★★★★
()
Ответ на: комментарий от kss

Основная задача микроядра — обмен сообщениями между процессами. Если в Линуксе, например, реализовать этот kdbus, который, как я понимаю, будет абстрактно выше обычного IPC, то можно будет в теории кучу всего вынести в юзерспейс.

ИМХО.

post-factum ★★★★★
()

Просто желаю достойной реализации отличной идеи.

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

Такая паника была бы равноценна тому, что падает то же микроядро от того, что какая-то программа посылает сообщения. При должных проверках на переполнения паник не возникнет.

post-factum ★★★★★
()
Ответ на: комментарий от firestarter

поначалу - будет обязательно.

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

На опеннете писали, что на синтетических тестах прирост производительности в два раза, на реальных – на четверть. Я не впечатлён.

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

Идея хороша, но для подобной задачи у dbus'а вроде бы сильный оверхед. Он вроде бы xml'м обменивается, нет?

KblCb ★★★★★
()

> Пожелаем удачи проекту, а также включения в «ванильное» ядро и большинство дистрибутивов.

нет.. спасибо.. я пожелаю обратного :-)

mkfifo
()

Давно бы так.

Deleted
()

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

ttnl ★★★★★
()
Ответ на: комментарий от post-factum

>Это, конечно, супермегаафигенно

Вы так говорите, как будто dbus основная причина тормозов в линуксе.

ttnl ★★★★★
()

Здравствуй, Linux Максимальная, что ли?

maxkit
()
Ответ на: комментарий от post-factum

> При должных проверках на переполнения паник не возникнет.

При должнык проверках защита памяти не нужна. А еще при должных проверках софт не глючит.

В микроядерной архитектуре как раз для меседжинга осуществлятся переход юзерспейс-ядро - что является аргументом противников мультиядерности относительно тормозов.

r ★★★★★
()
Ответ на: комментарий от post-factum

> А как же микроядерные сервисы на пользовательском уровне должны обмениваться сообщениями?

перемапливание памяти MMU + copy on write

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

Вроде да, xml. Для уровня ядра мне кажется это слишком (в ядрах не разбираюсь). С другой стороны если это будет завёрнуто в libdbus, то на уровне ядра вполне может ходить и не xml.

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

:) из конфигов наверное.

по сабжу, не нужен сабж. Там прироста даже 25 процентов не было. А много ли юзкейсов когда узким местом является dbus. Empathy, у которой все на dbus imho более частный случай, чем закономерность.

mrdeath ★★★★★
()

25% - это на самом деле офигенный прирост... там некоторые ради 5-7% готовы улучшать и минимизировать, а тут целых 25...

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

anonymous
()

реалии жизни плавно так, незаметно приближают нас к глубокому осознанию правоты Таненбаума... :D

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

Прчием тут микроядро-то, объясните? Микроядро — это когда в ядро тащат всё подряд, что ли?

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

+1, нормальные люди уже давно всякую хрень из ядра в юзерспейс вытаскивают, а какие-то извращенцы пытаются вместо этого натаскать в ядро новой хрени.

INFOMAN ★★★★★
()

сначала про kde подумал. KDE - графический рабочий стол внутри ядра для увеличения быстродействия.

zyoung
()

не понимаю - что все так переполошились? Доведут (если не забросят) сабж до того, что бы его включили (официально) в ядро - посмотрим.

зы. во всяком случае - menuconfig никто еще не отменял...

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

>>Разве обычную очередь сообщений в Linux уже отменили?

Про то и речь. Ядро как бы один процесс. Юзерспейс программа -другой. Области памяти разные, в общем случае недоступные друг другу. Защита реализована в железе на различных архитектурах. В стандартном варианте надо сохранить кой какие регистры, да скопировать одну область памяти в другую. Последняя операция прямо пропорциональна объему передаваемых данных. В 64 битных интелях за такт можно передать что-то около 128 бит данных, при нынешних объемах не так много. Идея, насколько понял, в достаточно безопасной реализации «общей памяти», чтобы избежать процесса копирования. В общем - штука интересная.

anonymous
()

Желаю проекту поскорее сдохнуть, чтобы не захламлять ядро.

Quasar ★★★★★
()

А для меня это было ожидаемое событие - т.е. я давно думал, что к этому идёт. Правда, не так скоро. Хотя, как черновик - наверное, время.

ximeric
()

For the unaware, DBus already allows private buses that allow direct peer-to-peer communication. AFAIR it was introduced exactly due Telepathy’s heavy weight usage of DBus to talk to peers. So it’s a moot point to suggest that, it’s already there and being used.

zyoung
()

В целях увеличения производительности компьютера представлен проект Kdbus

Не путать с kdbus 0.8.6, который является просмотрщиком D-BUS в KDE, как kdcop для DCOP.

lystor ★★
()

Действительно непонятно, чего все переполошились?

Ну будет ещё один способ обмена - на этот раз сообщениями только в конкретном формате. Ну и что с того то?
Все системы в том или ином виде поддерживают обмен данными.
Если не подходят текущие способы обмена информацией - делают новые. Вот и всё!

Идею в принципе - поддерживаю. Посмотрим на реализацию.

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