LINUX.ORG.RU

unbuffered IPC

 , , ,


0

3

Если ли тут знатоки (не «балаболки» (с)) MM ядра (linux конечно)?

Хочется странного, а именно - запилить IPC таким образом чтобы вместо copyfrom/copyto из какого то буфера (как например в pipe) мне подмапливалась память (векторами например) RO (да есть детали - например если случается pfault то если буфер может быть интактным, то уже подставлять другую страницу копируя данные из той, причем копирование в целом можно и на уровне libc оставить - мелочи и детали это все).

то есть как пример - вместо read(fd, void *, size_t) что то типа ublablaread(fd, vecs_t**, size_t *) тоже с write.

Осмотрев объем mm в ядре - хочется получить совет с чего начать в этом не очень то и сложном мероприятии и узнать какие либо потенциальные подвохи с mm реализацией в современном ядре. Штудировать какую то специфику в одно лицо - долго.

PS да для файлов на fs есть mmap, но хочется странного - а именно работать не только с объектами fs в таким виде (буферы сокетов например).

Я в теме не разбираюсь, но вроде бы правильные ключевые слова это vmsplice() и SPLICE_F_GIFT / SPLICE_F_MOVE.

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

да если так то в мане на splice, например, про флаг SPLICE_F_MOVE написано вот что

Attempt to move pages instead of copying. This is only a hint to the kernel: pages may still be copied if the kernel cannot move the pages from the pipe, or if the pipe buffers don't refer to full pages. The initial implementation of this flag was buggy: therefore starting in Linux 2.6.21 it is a no-op (but is still permitted in a splice() call); in the future, a correct implementation may be restored.

in the future, a correct implementation may be restored.

как то это что то не внушает оптимизмов.

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

Если хочется работать с сокетами, то для этого есть SOCK_PACKET, и не надо ничего велосипедить. Правда IP стек нужно будет самому прикручивать

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

Если хочется работать с сокетами, то для этого есть SOCK_PACKET, и не надо ничего велосипедить. Правда IP стек нужно будет самому прикручивать

читал, тоже не то. а с slice()/vmslice() проблема с fd, то есть его проброской в случае когда надо «пайповый» метод заменить.

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

Если хочется работать с сокетами, то для этого есть SOCK_PACKET, и не надо ничего велосипедить. Правда IP стек нужно будет самому прикручивать

посмотрел код. обратите внимание - net/packet/af_packet.c именно в ф-ции tpacket_rcv() например, юзается skb_copy_bits() то есть таки копируется, конечно это не в/из юспейса и куда быстрее, но я был б готов запилить либу, которая вместе с хедерами в зависимости от пропускала б их :) ну и мне надо универсальное решение это пункт 2. не хочется мешать мух со слонами в коде. то есть в моей специфичной задаче (ядро 4.4.13 с патчами потому как забинден на него по определенным причинам) могу добавить еще патч, но времени на полный investigation mm у меня не особо то чтоб и много.

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

не подходит? Я правда не очень понял что именно ты хочешь, гонять данные между процессами без копирования? shared memory тебе тоже не подходит?

memfd_create() нет. я хочу универсальное IPC которое бы избегало copyfrom/copyto тк из юспейса в ядро и обратно это большой bottleneck. что то вроде iolite.

in general - допустим есть демон, допустим у него unix socket, и с каждым клиентом он обменивается не read/write что ведет к этим копированиям, а вот этими подмапленными кусками памяти, причем мапятся они readonly и перемапить их на readwrite нельзя. опционально сделать так что если в этот кусок идет запись то страница эта подменяется другой - уже его и туда данные memcpy() в юспейсе переписываются, а сверху что то типа blablabuf. Почему универсальный, потому как сегодня unix socket завтра там уже udp с своим протоколом поверх. ну и в некоторых случаях это может быть файл, девайс с дровиной умеющей в DMA etc ...

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

В такой формулировке только лепить самостоятельно.

понимаю, поэтому вопрос и ставил - куда смотреть в mm, чтоб по нему долго не лазить в поисках истины и какие есть стремные моменты. И на всякий случай - может уже что то такое запилили (на самом деле не запилили уже обыскался).

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

shmem

если б все так было б просто, то я б не задавал вопрос тут, а юзал б shmem давно :)

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

PS да для файлов на fs есть mmap, но хочется странного - а именно работать не только с объектами fs в таким виде (буферы сокетов например).

Mellanox ROCE, не знаю допилили ли они драйверы до юзабельного состояния. mmap на socket не возможен по причине того, что ты просто не сможешь обратиться к рандомному региону памяти в socket.

Но если ты совсем сильный духом, то бери https://github.com/torvalds/linux/blob/master/Documentation/networking/packet...

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

Mellanox ROCE, не знаю допилили ли они драйверы до юзабельного состояния.

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

mmap на socket не возможен по причине того, что ты просто не сможешь обратиться к рандомному региону памяти в socket.

это смотря как устроен стэк и его буферы, ну то есть в случае с linux есть реализация в ядре, которая создает еще один буфер — который и мапится, но в него данные попадают копированием из skb буфера - я там выше писал.

Но если ты совсем сильный духом, то бери https://github.com/torvalds/linux/blob/master/Documentation/networking/packet...

не вижу ничего там такого сильного.

суть в том что мне для каждого кейса городить свой огород получается надо. и потом оборачивать это все, причем не факт что красиво получится сделать в принципе. да, такие вот монолиты :)

а хочется

in general - допустим есть демон, допустим у него unix socket, и с каждым клиентом он обменивается не read/write что ведет к этим копированиям, а вот этими подмапленными кусками памяти, причем мапятся они readonly и перемапить их на readwrite нельзя. опционально сделать так что если в этот кусок идет запись то страница эта подменяется другой - уже его и туда данные memcpy() в юспейсе переписываются, а сверху что то типа blablabuf. Почему универсальный, потому как сегодня unix socket завтра там уже udp с своим протоколом поверх. ну и в некоторых случаях это может быть файл, девайс с дровиной умеющей в DMA etc ...

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

Ну так может не трясти ядро под каждую хочушку, а таки сделать демон, который слушает этот злочастный udp, разбирается, что там потеряли чтобы перепослать по протоколу, разбирается сколько надо буфферизовать, а сколько выкидывать по принципу ушедшего поезда, а потом уже это всё дело раздавать по shmem?

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

Ну так может не трясти ядро под каждую хочушку, а таки сделать демон, который слушает этот злочастный udp, разбирается, что там потеряли чтобы перепослать по протоколу, разбирается сколько надо буфферизовать, а сколько выкидывать по принципу ушедшего поезда, а потом уже это всё дело раздавать по shmem?

и таки иметь copyto/copyfrom в этом демоне так ? тогда смысл в нем вообще не понятен.

тогда уж проще AF_PACKET и сверху все в либу запихать, вывести один общий API наружу. для сокетов будет работать.

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

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

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

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

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

Реальное время и общая производительность - это разные вещи.

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

Т.е. просто zero-copy?

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

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

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

а при чем тут реальное время ?

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

ой, как же достали эти типа умники.

для вумных поясняю - реальное время != высокая производительность, заруби себе это на носу и больше не позорься тут. реальное время это гарантированное выполнение операции за гарантированное время, 1µs или 1min это не важно. И во многих кейсах не real time системы работают быстрее тк используют другие алгоритмы и не учитывают тот самый real time. например в real time стоимость будет всегда O(log n) и где этот n строго ограничен и его max это и есть то гарантированное время, а не в real time будет худший кейс O(n*2) а лучший O(log n/2) ...

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

Я к тому что ему лезть в такие дебри не надо если у него нет хард-рилтайм необходимости.

ты опять балаболишь. причем тут хардрилтайм ? делать сисколл и copyto/copyfrom kernel/uspace на каждый чих это ооооочень долго. особенно если это протокол поверх udp или сообщение другого локального процесса (дада, такой вот кейс что надо гонять между ними локально достаточно много).

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

Два процесса с общей памятью, и через эту общую память обмениваются. Вот и IPC

два процесса, один потомок другого.

в моем случае это n процессов и вовсе не родственные.

а до схемы с shmem, любой б идиот бы догадался, может я и идиот, но если б меня shmem и прочее устроило — очевидно я б не полез сюда с вопросами.

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

Железо купи, долгий, и перестань дрочить.

ясно, понятно. ты — дебил.

Потом кому-то твое говно поддерживать.

балабол ты. тебе показали что ты херню несешь, что ты технически никуя не соображаешь, пустозвон ты, а ты продолжаешь нести херню. ну теперь так и запишем - lovesan некомпетентный дебил. зачем сюда лезешь в технический форум ? иди лучше на форум домохозяек - пиши что там им железо надо покупать :)

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

futex + mmap. есть библиотека как раз про это но я забыл название.

а из мелкого нонейма - memshare

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

ты опять балаболишь. причем тут хардрилтайм ?

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

Может сначала стоит заняться профайлингом ? А то вдруг окажется что «делать сисколл и copyto/copyfrom kernel/uspace на каждый чих» при тяжелой нагрузке генерирует пренебрежительно мало CPU load по сравнению со всем остальным что там в это время происходит ...

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

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

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

Может сначала стоит заняться профайлингом ? А то вдруг окажется что «делать сисколл и copyto/copyfrom kernel/uspace на каждый чих» при тяжелой нагрузке генерирует пренебрежительно мало CPU load по сравнению со всем остальным что там в это время происходит ...

да откуда вы все такие умные беретесь сначала ? а вам в голову не пришло что это уже было сделано и что проблему уже нашли ? не ?

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

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

да и таки тут хардрилтайм тут нипричем - от слова совсем, без всяких вероятно.

и я просил не лезть в эту тему балаболок. это в talks балаболить надо.

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

да откуда вы все такие умные беретесь сначала ? а вам в голову не пришло что это уже было сделано и что проблему уже нашли ? не ?

В описании задачи про это ничего не сказано, а телепатов тут практически нет. Зато в описании задачи есть «Хочется странного», «Штудировать какую то специфику в одно лицо - долго» etc, и почему-то сразу в памяти всплывает загадочное словосочетание «The XY Problem»

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

да и таки тут хардрилтайм тут нипричем - от слова совсем, без всяких вероятно.

хардрилтайм тут при том что это одна из тех задач для решения которой я возможно полезу патчить ядро, так как из userspace она решается тяжело. Да и то ввиду наличия PREEMPT_RT скорее всего в этом сегодня нет необходимости

и я просил не лезть в эту тему балаболок. это в talks балаболить надо.

Вряд ли ты здесь найдешь специалистов нужной квалификации по mm. Рекомендую написать в «Спортлото» LKML. Если нормально опишешь задачу то наверняка посоветуют что-нибудь полезное а то глядишь и новую фичу в ядро добавят. Но наверное лучше сначала возьми отпуск, отдохни. А то за такой стиль ведения дискуссии там и обидеть могут

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

хардрилтайм тут при том что это одна из тех задач для решения которой я возможно полезу патчить ядро, так как из userspace она решается тяжело. Да и то ввиду наличия PREEMPT_RT скорее всего в этом сегодня нет необходимости

логика где ? кто то полезет, кто то не полезет. в linux RT боюсь никогда не завезут, но да ладно.

Вряд ли ты здесь найдешь специалистов нужной квалификации по mm. Рекомендую написать в «Спортлото» LKML.

там предложат что то запихать в ядро да.

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