Почему хранение процессов в виде файлов в `/proc `не влияет на производительность?

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

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

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

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

Пример :Процесс может получить память в куче через malloc. Ядро знает, что процесс выделил память, и представляет эту информацию через /proc/…/maps. Процесс будет использовать память напрямую, обращаясь к указателю, а не выполняя ввод-вывод на /proc/…/mem.

Файлы в /procи /sysсуществуют чисто динамически, т.е. когда их никто не читает, их вообще нет и ядро ​​не тратит время на их создание.

Файлы /procи /sysможно рассматривать как вызовы API. Если вы их не выполняете, ядро ​​не запускает никакого кода

Другой способ думать о /procфайлах состоит в том, что, хотя «все является файлом», не каждый файл представляет собой байты, хранящиеся на диске.

Для файлов /procоперации чтения выполняются ядром, динамически генерирующим необходимые байты на основе состояния запущенных процессов, а не извлекая байты из дискового хранилища.

Аналогичным образом записи в /procфайлы (, где разрешено ), взаимодействуют с ядром, а не с байтами на диске.

Термин «файл» здесь сильно перегружен. Это может означать файл, хранящийся на реальном диске, но в данном случае это означает все, доступ к которому осуществляется с помощью файлового API :, открытие, чтение, запись и закрытие.

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

Традиционно файлы устройств имели записи на диске, чтобы упростить поиск пути, но это было бы неэффективно для procas sysфайловых систем, поэтому они также имеют настраиваемый поиск и ничего не записывают на диск. вообще. Так же как и файловая система tmp, которая просто хранит данные в кеше (и, возможно, выгружает их в общий своп ).

Таким образом, когда вы не обращаетесь к ним, вообще нет накладных расходов. Когда вы это сделаете, все, что вам нужно, это выделить dentry, inode и файловые структуры в ядре (, чтобы связать файловый дескриптор с )и отформатировать информацию из внутренних структур ядра. Это немного медленнее, чем выделенный API, но позволяет избежать добавления дополнительных точек входа -в ядро ​​и позволяет использовать существующие утилиты для обработки информации.

При выполнении системных вызовов openи closeвозникают некоторые ненужные накладные расходы. Это одна из причин предложенного введения системного вызова readfile.

Накладные расходы, связанные с использованием файловой системы с именами ASCII для /proc и /sys, полностью оправдывают себя, если рассмотреть альтернативы. В очень плохие старые времена программы должны были иметь root-права SUID, чтобы они могли читать память ядра и анализировать двоичные структуры процессов. Это ужасно глючило, если пользовательское пространство и ядро ​​​​рассинхронизировались. Также невероятно много ошибок, когда в системах было несколько процессоров, и структуры процессов ядра могли изменяться при чтении без блокировки.

Я полагаю, что некоторые из BSD решили использовать форму доступа ioctl или netlink, которая дает им двоичный доступ к данным процесса без непосредственного чтения ядра.Это более эффективно, чем procfs, но очень затрудняет использование из оболочки и языков сценариев.