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

работает ОЧЕНЬ быстро

Так-то оно так, но DBus насколько мне известно необходим для обмена инфой между прикладными процессами. В таком случае хоть разделяемую память используй быстрее некуда. Зачем городить ещё один IPC? Linux не микроядро поэтому оптимизация работы очереди сообщения для обмена инфой м/у сервисамми и микроядром не нужна.

Вопрос что в этом IPC нового? Если не устраивает текущая реализация очереди сообщений пусть патчат ядро и совершенствуют.

Годный подход

> Kdbus

Для работы будет требовать kde-libs?

Ну как дети - всякую гадость в ядро тянут. Конечно обмен по dbus - это такая критичная вещь, которую срочно надо соптимизировать. Там же гигабайты данных таскают..

>KVM/i386, with kdbus:Fetched 300000 rows in 24368ms (26% faster - x1.35)

26% прироста производительности - отличный результат. Если работа не захлопнет, то когда допилят интересно будет пощупать его «живьем».

1. Вопрос не ко мне.
2. Ломать существующее? 8)
Да его потом съедят жЫвьём! Уж не говоря о внедрении функциональность в ядро. И будут правы!

Данный шаг позволит повысить производительность D-BUS до максимально возможного уровня, ведь так? А если так, то это просто отлично. Желаю успехов создателям этого проекта и скорейшей реализации важной нужной вещи!

И попутно вопрос: во всех современных дистрибутивах трей (область уведомлений) работает через D-BUS. Так это работает в KDE 4 и есть ли это в Gnome 2.30 например?

И напоследок: почему применяется копирование а не, что намного проще и быстрее, просто передача страницы памяти во владение другому процессу?

Это неверный путь. D-Bus - не настолько критичная по времени выполнения штука, как скажем fuse. Десктопу - десктопное, нефиг тащить в основную ветку ядра всякий хлам.

Это неверный путь. D-Bus - не настолько критичная по времени выполнения штука, как скажем fuse.

Не согласен. Такая вещь как D-BUS должна быть максимально быстрой, чтобы можно было организовать эффективное взаимодействие между программами, службами и т.п. Чтобы чуть ли не драйверы можно было в юзерспейсе писать для ядра.

Даже не знаю. Посмотрел в wiki, действительно не видно. Даже странно, откуда такая ассоциация :-) Но это даже хорошо же.

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

ИМХО для таких целей dbus толстоват.

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

26% прироста производительности - отличный результат.

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

Для того, что должно работать быстро, есть стабильные ext? и reiserfs. А всякие там самбы и прочие блаблабла теперь при каком-то косяке вылетят тихо и мирно, а не потянут за собой kernel panic.

>годная идея для linux 2.8.
Плюсую.

Угу, когда в ядро притащат стопицот таких «26% приростов производительности», то там получится уже не 26, а слегка поменьше, вкупе с весьма забавными эксплойтами и кернел паником напоследок.

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

Ну да, а потом мужественно убеждать друг друга мантрой «а у меня Plasma не падает».

1) реальное ускорение в 25% для вещи, которая только и делает что кидает куски текстовой (XML же) не-реалтайм информации между процессами - полный отстой, и если не перегружать свой софт её использованием - разница будет даже незаметна для глаза.
2) D-Bus - отнюдь не вышеупомянутый IPC, который должен быть критически быстрым, это - повторяю - лишь десктопная приблуда для обмена текстом. для обмена межпроцессной информацией по firewire тоже будем пользоваться d-bus?
3) всё это не нужно, так как предел при упоре на связь между процессами внутри ядра равен микроядерной архитектуре, и Линус не согласится на полный рефакторинг своего детища - у них с Таненбаумом была куча срачей на эту тему в самом начале. если запилить Kdbus и сделать на него упор при проектировании софта - ядро линукса превратится в пятнадцатиногого слона с головой орангутанга и внешностью мэрилин монро.

сначала мне самому понравился сабж, но потом я подумал.

Танненбаум давно уже говорил...

Сходил по ссылке. Увы. Это не прорыв в области копирования данных из юзерспейса в кернелспейс. Это что-то вроде умной маршрутизации: для пересылке сообщения демону-брокеру и обратно используется не обычный сокет, а волшебный, который может сказать «Ба! Да я знаю куда этот меседж! Дай ка я его сразу на сокет получателя заверну.»

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

гм, ну локально может кто-то и отменил в пользу nconfig :)
По сабжу: будем смотреть, что они там сделают. Если честно, это была недавная мысль, что обмен сообщениями между приложениями как-то логичнее проводить в ядре. Другое дело, что подход в DBus какой-то непонятный с этими их длинными «классами»... машине, конечно, сугубо пофиг, но вот понимать все эти super.app.My.doc.Dongle.Org.что-то там ещё... а делов-то... почитать мануал по дбасу)) чем возможно сейчас и займусь.

D-Bus is low-overhead because it uses a binary protocol, and does not have to convert to and from a text format such as XML.

http://dbus.freedesktop.org/doc/dbus-specification.html#introduction

Я знаю, в ядро нужно плазму засунуть. Заодно и разберемся, падает она или нет =)

1) Может ли D-Bus обмениваться бинарными данными? Я не очень в курсе этой шины...

2) Если не он, то что может лучше подойти для быстрого обмена _бинарными_ данными между процессами?

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

Зачем? Какой взаимодействие между службами потребует значительного потока данных?

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

Через DBUS? Ты в своем уме?

В своей войне с XML неплохо бы проверять факты прежде чем :}

>Какой взаимодействие между службами потребует значительного потока данных?

Меню через DBUS уже нарисовали. То ли ещё будет.

>> Какой взаимодействие между службами потребует значительного потока данных?

Меню через DBUS уже нарисовали.

Меню - это копейки^Wкилобайты в худшем случае.

Так это пока, я в них верю! :) Да и Empathy уже упомянули, мало ли ещё таких монстров будет (хотя у меня его нет, не знаю насколько куча таких программ бы влияла на производительность).

Идея быстрого IPC между ядром и юзерспейсом и в комбинациях меня очень возбудила. Если не D-Bus, то что - какие есть аналоги?

И повторю свой другой вопрос - почему не переназначение владельца страницы памяти, а именно копирование применяют?

На самом деле, есть такие штуки, например, тот же Tracker --- локальный поисковик для GNOME. В настоящее время там используется следующий подход: поисковый запрос идет через D-Bus, в ответ возвращается дескриптор на анонимный pipe (D-Bus умеет пробрасывать через себя файловые дескрипторы, не могу сказать, насколько это завязано на возможность пробрасывать файловые дескрипторы через Unix socket) и по этому pipe клиенту поиска приходят данные, являющиеся ответом.

На самом деле, ускорение D-Bus важная и полезная задача и дело не только килобайтах, но и в конском round trip time.

Одновременно с тем, очевидно, что начинать оптимизации D-Bus с создания AF_DBUS --- довольно странно, если не сказать глупо. D-Bus делает еще кучу бесполезной (или почти бесполезной) работы. Свидетельством этого являются, например, сравнительные измерения D-Bus с похожим методом IPC --- Orbit: http://live.gnome.org/GAP/AtSpiDbusInvestigation#DBus_and_ORBit_Benchmarking

Для общего просвещения в вопросах ускорения D-Bus стоит почитать умных людей в мэйл-листе: http://lists.freedesktop.org/pipermail/dbus/2010-January/012066.html

Хорошая идея, давно бы так! Всяко лучше, чем тащить в основную ветку всякие женоубицфс.

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

Плохой пример. FUSE больше подходит для небольших костылей вроде ФС через OBEX или MTP, когда ядерный модуль избыточен и слишком сложен.

Также FUSE позволяет использовать что-то кроме С

эмм... Копируют, потому что передаваемая ядру информация не обязательно кратна странице, страницы приложению тоже нужны, аллокаторы в либс вообще ничего об этом не могут знать и т.д. Быстрый обмен - разделяемая память, медленее и абстрактнее - месседжи и unix сокеты . dbus для обмена сообщениями между юзерспейс, причем тут ядро. По ссылке не ходил, но, видимо, речь ведется просто о поддержке dbus на ядерном уровне, какую-то микроядерность приплели...

в zen и ядре бубунты он будет точно.

Если не он, то что может лучше подойти для быстрого обмена _бинарными_ данными между процессами?

msgrcv и msgsnd?

> На самом деле, есть такие штуки, например, тот же Tracker --- локальный поисковик для GNOME

То есть из-за того, что какие-то странные люде не осилили использование IPC с нормальной производительностью, нужно вводить в ядро всякий мусор?

Для общего просвещения в вопросах ускорения D-Bus стоит почитать умных людей в мэйл-листе: http://lists.freedesktop.org/pipermail/dbus/2010-January/012066.html

Ты сам-то читал? «in all reality the current setup works fine and is portable to almost any operating system». Но умельцам народным неймется...

Уши бы оторвал

Для нормального IPC ядру не хватает одной единственной вещи: именованных mailboxов.

это аналог очереди сообщений, но с множеством чтецов, каждый из которых получает копию сообщения. чтоб в mailbox лежало только одно сообщение, например, и его можно было прочитать много раз, и pollить. всё остальное должно быть на уровне юзера.

авторов велосипеда пороть. посылаю также луч говна тем, кто суёт xml куда не попадя.

это можно съэмулировать через mmap (узеры в readonly) + сигналы, но гемморой состоит в запоминании, каким процессам надо послать сигнал и слежении за ними. плюс, mmap - это весьма не быстрая и к тому же расходующая vmarea вещь

ЗЫ: рассуждающим про FUSE - как разраб говорю, что fuse оооочень хорош в теории, для создания хитрожопых ФС с небольшой нагрузкой - т.е. того, что нужно на десктопе. например корневая сжатая фс для мелких дистрибутивов, загружаемых с потенциально выдирабельной флешки(сам делал).

но фуз имеет API такой, будто на него внимательно смотрит свиборг. он уродлив чуть более, чем полностью. аргументы не удобны для использования(файлы нужно идентифицировать числом, хотя бы 64битным атомарно инкрементируемым-на i386 это тоже делается без блокировок), сам api избыточен, разрабы просто должны делать все основные библиотечные вызовы для работы с файлами. poll не поддерживается и т.д. и т.п.

> poll не поддерживается и т.д. и т.п.

А poll на дескрипторах дисковых файлов вообще поддерживается?

Строго говоря, есть в виде DBus.Introspectable. Но сам протокол да, бинарный.

+100500 DBUS в таком виде, как он есть в ядро пускать нельзя!!!

> Всяко лучше, чем тащить в основную ветку всякие женоубицфс.

Вы намекаете на то, что ФС якобы плоха из-за того, что автор совершил убийство?

конечно работает.

на уровне сисколлов это aio_xxx но в струтуре file_operations за это отвечает poll()

http://lse.sourceforge.net/io/aio.html Buffered filesystem AIO, i.e. AIO read and write on files opened without O_DIRECT, on ext2, ext3, jfs, xfs, reiserfs.

>> А poll на дескрипторах дисковых файлов вообще поддерживается?

на уровне сисколлов это aio_xxx

Ну то есть poll(2) не поддерживается, об этом и был вопрос.

в струтуре file_operations за это отвечает poll()

Детали мало кому интересны.