ктото делал сравнительный анализ реализаций IPC на шаренной памяти + спинлок и unix sockets + select()

Вас сравнение по какому параметру интересует? По бакланизму вроде первый в разы лучше.

Меня интересует баланс между пропускной способностью и загрузкой проца. латентность на текущем этапе не интересует.

Сейчас данные льются со скоростью 20 Мб/сек и это процентов на 10 загружает проц. меня это смущает. я ожидал что при такой нагрузке загрузка проца не должна подыматся выше 1%.

Лучше максимальный performance мерять, а то мало ли чего там 10%. У меня так бывает если в не правильных местах мышкой подвигать

Подозреваю, что эффективнее всего будет sendfile

ну текущая реализация работает так: ридер читает из usb через libusb и пишет в шаренную память а потом врайтер вычитывает из шареной памяти и пишет на диск. но при этом у меня еще есть задача опционально отвязать все это от диска. не уверен что sendfile здесь поможет.

ридер читает из usb через libusb

Да, здесь вряд ли есть mmap... хотя я бы проверил :)

не уверен что sendfile здесь поможет.

Ну, если ты склонен к извр^Wнеобычным решениям: мапишь файл, читаешь из USB данные в замапленный кусок, делаешь sendfile замапленного файла. Сам файл может жить в tmpfs.

Еще можно попробовать splice.

за splice() спасибо. это нововведение меня обошло стороной

а зачем тебе select для случая с unix sockets? читай в блокируемом режиме да и всё. или у тебя там ещё куча сокетов, на события которых нужно реагировать?

А нафиг тебе при такой задаче вообще спинлок?

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

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

Я думаю, что там просто CAS (compare and swap) можно обойтись. И даже просто swap, без compare.