Какая проблема с производительностью dbus может помешать встроенной системе?

Question

Из моего чтения производительность dbus должна быть в два раза ниже, чем у других механизмов ipc обмена сообщениями из-за существования демона.

При обсуждении вопроса о том, какую технику Linux IPC использовать, кто- то упоминает проблемы с производительностью. Видите ли вы проблемы с производительностью, кроме вдвое более медленного фактора? Видите ли вы проблему, которая препятствует использованию dbus во встроенной системе?

Насколько я понимаю, если dbus предназначен для небольших сообщений. Если необходимо передать большой объем данных, одним из решений является помещение данных в общую память или в стопку, а затем использование dbus для уведомления. Другие механизмы ipc в соответствии с рассматриваемым обсуждением: сигналы, анонимные каналы, именованные каналы или FIFO, очереди сообщений SysV, очереди сообщений POSIX, общая память SysV, общая память POSIX, семафоры SysV, семафоры POSIX, блокировки FUTEX, блокировки файлов, резервная и анонимная разделяемая память с использованием mmap, доменных сокетов UNIX, сокетов Netlink, сетевых сокетов, механизмов Inotify, подсистемы FUSE, подсистемы D-Bus.

Я должен упомянуть еще один вопрос, в котором перечислены требования (хотя он и основан на apache):

• ориентированный на пакет / сообщение
• способность обрабатывать как точка-точка, так и связь один-ко-многим
• нет иерархии, нет сервера и клиента
• если одна конечная точка дает сбой, другие должны быть уведомлены
• хорошая поддержка существующих дистрибутивов Linux
• существование "привязки" для Apache для целей создания динамических страниц - это слишком специфично, но это может быть проигнорировано в общем обсуждении использования встроенного dbus

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

Answer 1

Я не думаю, что существует какая-то реальная проблема производительности.

Сделал некоторое профилирование:

• На 200 МГц процессоре arm926ejs вызов метода и ответ с двумя аргументами uint32 потребляют от 0 до 15 мс. в среднем 6 мс

• Изменен 2-й параметр на массив из 1000 байтов. Если использовать итерацию api для упаковки и распаковки 2-го параметра, это займет около 18 мс.

• Тот же 2-й параметр массива 1000 байтов. Если использовать api фиксированной длины для упаковки и распаковки второго параметра, это займет около 8 мс.

• Для сравнения используйте SysV msgq, передающий сообщение другому процессу и получающий ответ. Это тоже около 10 мс, но без оптимизации кода и повторения теста для большого количества выборок.

Таким образом, профилирование не показывает проблемы с производительностью.

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

Редактировать: если вы отправляете сообщения напрямую в обход демона, производительность удваивается.

Answer 2

Итак, альянс Genivi, нацеленный на автомобильную промышленность, внедрил и поддерживает CommonAPI, который работает поверх DBUS, в качестве механизма IPC для головных устройств автомобилей.