LINUX.ORG.RU

Системный вызов read для shm, pipe

 , , , ,


1

1

1. Для считывания данных из stdin используется syscall read, но как дела обстоят с shared memory?
2. Будет ли сказываться на работе системы нагруженный IO при работе с пайпами? Копирование данных на флешку, например, приводит к сильным зависаниям системы (нагрузка процессора при этом не больше нескольких процентов).
3. Есть ли операционные системы, где системный вызов read находится в пространстве пользователя? Увеличится ли при этом скорость отправки данных? Нужно ли?
4. В каком виде будет храниться массив в shm?

3. Есть ли операционные системы, где системный вызов read находится в пространстве пользователя?

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

IvanR ★★★ ()
Ответ на: комментарий от sharkvi
for (i = 0; i < sizeof(array); i++) {dst[i] = src[i]};

ядро заранее заботится, чтобы адреса были видны из обоих процессов.

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

IvanR ★★★ ()
Последнее исправление: IvanR (всего исправлений: 1)

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

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

Почему тогда пайпы реализованы не через shm?

ls | grep a
stdout первой команды связан с stdin второй, значит в shm держим один байт: 1-ая команда сохраняет байт там, 2-ая использует этот байт и удаляет его из shm, потом 1-ая сохраняет следующий байт и т.п. И всё это без лишнего копирования и дерганья ядра командой read - разве нет?

sharkvi ()

если хотите знать, как устроены read/write стандарнтых потоков Linux, то смотрите в драйвер /dev/pts/[0-9]

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

Почему тогда пайпы реализованы не через shm?

где реализованы?

если вы читаете с диска, то реализация read/write будет в ext4, если чиатете /proc, то реализация read/write будет в драйвере proc и т.п.

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

может так и устроено, при создании pipe не обязательно обращаться в ядро, тогда библиотека сама должна отслеживать, куда идет вызов read/write и если вызов идет к pipe, то достаточно использовать стандартную библиотеку, однако в таком случае, если вы сделаете вызовы read/write без помощи библиотеки, то есть непосредственно в ядро (это можно сделать с помощью ассемблерных вставок) то такой вызов не увенчается успехом.

Почему тогда пайпы реализованы не через shm?

если это сделано не через shm, значит это сделано для унификации интерфесов, если через shm, значит ассемблерной вставкой сделать вызов read/write к pipe не получится.

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

А когда именно им «сохранять», «использовать» и «удалять» этот байт они конечно же поймут, вызвав generic_guess(NULL) из libastral.so. Без лишнего дерганья ядра.

anonymous ()

2. Будет ли сказываться на работе системы нагруженный IO при работе с пайпами? Копирование данных на флешку, например, приводит к сильным зависаниям системы (нагрузка процессора при этом не больше нескольких процентов).

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

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

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

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

бласть занятая - используем и удаляем, пустая - записываем.

это делается на основе мьютексов или семафоров

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

1. Тогда какие типы данных можно там хранить? Всё, что есть в C?
2. Почему dbus не выбрал способ передачи данных именно через shm? Для сообщений: программа А хочет отправить сообщение, вызывает функцию из libdbus, в качестве параметра указываем получателя и сообщение -> создается в shm переменная-строка с сообщением, имя переменной отправляется на шину, с нее к приложению-получателю, она обрабатывает строку и подчищает за собой (для халявщиков можно ввести глобальное ограничение: сообщения хранятся только 5 минут, например). Этот способ можно приплести ко всем возможностям dbus'а в качестве обмена информацией. Как идея?

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

Тогда какие типы данных можно там хранить? Всё, что есть в C?

все, что можно хранить в памяти, так как shm это и есть обычная память.

2 не работал с libdbus, не могу оценить.

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

Идея отличная — срочно кодируй, а то забудешь.

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

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

Почему dbus не выбрал

Хз. Возможно, слишком много возни, возможно, соображения безопасности. Скорее всего всё вместе.

Как идея?

Так и делают, см. http://nanomsg.org/documentation-zeromq.html (ищи «shared memory» в тексте)

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

Как мне понять, что он уже прочитал те циферки и можно писать новые?

Так же как и с обычной памятью: держать структуру данных для этого. Я не удивлюсь если кто-то уже придумал как с этим работать без блокировок (а может и нет, гугли lock-free shared memory). Как я писал выше, ipc через shared memory вполне себе существует. Есть даже круче трава, ipc через remote DMA.

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

man mit-shm. дибилиас в этом не нуждается, данных мало передаётся.

anonymous ()

Не понял, честно говоря, вопроса. Недосып-с.

Оффотоп: писали подсистему вывода информации на дисплей. Идея, вкратце, такая: несколько демонов-пользователей перехватывают информацию от владельцев сервисов и выводят её на участки экрана.

Всё было нарисовано, конечно, красиво, но я реально умучился с реализацией этого чуда-юда.

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

кто-то уже придумал как с этим работать без блокировок

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

Remote dma это такой же чит как shm через send/recv?

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

либо, либо

Это в лучшем случае. При кривой реализации со стороны продюсера можно начать терять пакеты.

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

1. Стоит ли считать работу связанных программ через stdin/stdout недостатком? Взять те же GNU-utils, например. При одновременном использовании.
2. Есть ли варианты без перекомпиляции заставить эти утилиты работать через nanomsg?
3. А с перекомпиляцией? Подойдет ли подменяемая библиотека-прослойка?

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

Как идея?

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

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от sharkvi

Стоит ли считать работу связанных программ через stdin/stdout недостатком?

У тебя какие-то филосовские вопросы. Ты уже убедился в том что у тебя пайпы это узкое место?

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