LINUX.ORG.RU

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

 , ,


0

0

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

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

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

★★

Проверено: annoynimous ()

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

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

А не наоборот, разве? Сделает ядро ещё более монолитным?

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

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

ИМХО.

post-factum ★★★★★ ()

годная идея для linux 2.8.

uju ★★ ()

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

Chaser_Andrey ★★★★★ ()

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

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

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

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

>микроядро?

Как-бы dbus это приблуда прикладных, и в основном gui прог. В микроядре же ipc для ядерных тредов.

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

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

post-factum ★★★★★ ()

Не там они узкие места ищут и оптимизацию проводят. Совсем не там.

linuxfan ()

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

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

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

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

Ну, если xml будет на уровне ядра, то нафик такое поделие.

post-factum ★★★★★ ()

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

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

mkfifo ()

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

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

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

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

ttnl ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

Как бы вот.

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

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

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

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

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

mrdeath ★★★★★ ()

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

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

anonymous ()

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

anonymous ()

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

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

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

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

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

INFOMAN ★★★★★ ()

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

zyoung ()

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

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

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

Например, был devfs — стал udev. Была куча глючных экспериментальных драйверов фс — стал fuse.

INFOMAN ★★★★★ ()
Ответ на: комментарий от 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 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.