Почему функции ядра, которые повторно реализованы в пространстве пользователя -, могут работать быстрее, чем в пространстве ядра -?
(скопировано из SU , где это по тем или иным причинам было закрыто)
systemd и syslogd не регистрируют вызовы сокетов.
Агент Check _MK -является «службой inetd» — это означает, что он не работает постоянно и не создает собственный сокет слушателя; вместо этого он полагается на "суперсервер" для выполнения этой работы. Каждое новое соединение принимается суперсервером, который затем запускает новую копию Check _MK для обработки этого конкретного соединения.
Традиционно для этой цели используются суперсерверные программы inetdили xinetd. Однако ваша недавно установленная система использует функцию «активации сокета» systemd для достижения того же самого — в этой системе сокет слушателя представлен модулем .socket, а каждый новый экземпляр представлен новым автоматически сгенерированным модулем .service..
Таким образом, сообщение журнала вовсе не о доступе к сокету — оно буквально говорит, что служба была запущена. Нет возможности отключить ведение журнала запуска службы.
Чтобы избавиться от этого сообщения, деактивируйте модуль systemd.socket и перенастройте агент Check _MK -так, чтобы он запускался через xinetd (или традиционный inetd, или любой другой альтернативой ).
Краткий ответ: ядру приходится иметь дело со многими различными ситуациями/приложениями/аппаратными средствами. Повторная реализация стека выполняется, когда вы знаете потребности своего оборудования и/или связи вашего приложения. Затем вы можете кодировать только для этой вселенной.
Допустим, у вас есть небольшое сенсорное устройство, которое периодически отправляет данные по протоколу UDP.Вы можете создавать пакеты UDP/IP с большинством фиксированных значений, чтобы они доходили до сервера (вы знаете свой IP, свой порт, порт назначения и адрес, длину сообщения, флаги... вам просто нужно изменить показания ).
Запуск полного стека IP-ядра только для этого был бы излишним, медленным и, возможно, даже невыполнимым(запуск внутри голых костей Arduino , например ).
Но более широкий ответ более сложен, поэтому я предлагаю статью:Почему мы используем TCP-стек ядра Linux , ссылка на которую приведена внизу цитируемой вами статьи.
Частично это позволяет избежать некоторых переходов через границу системного вызова.
Это верно, но другой аспект заключается в том, что интерфейс системных вызовов Linux одновременно является очень общим (, т.е. должен иметь дело со многими различными типами приложений и систем ), и очень узким (параметры системных вызовов очень важны. конкретно с текущим запросом только ). Ядро обычно почти не знает, что ваш код будет делать дальше.
Возьмем в качестве примера find. Он тратит много времени на системные вызовы, такие как getdentsи opendir. Вы можете делать многое с помощью find, но вот типичная командная строка:
find. -name 'report_201[89].txt' -print -quit
Программа findбудет открывать много каталогов и читать множество имен файлов. Он собирается передать эти имена файлов пользовательской -космической функции fnmatch, чтобы узнать, являются ли они report_2018.txtили report_2019.txt.
Но давайте предположим, что .находится в какой-то современной файловой системе. Каталоги на самом деле представляют собой B -деревья или хеш-таблицы. Если бы только ядро знало, какое имя файла мы ищем, мы могли бы сократить объем обработки.
Предположим, вместо этого мы рассмотрим git status. Если вы проследите его системные вызовы, он выдает массу вызовов lstat. Но на самом деле он пытается выяснить, изменил ли пользователь файловую систему? Ядро в основном знает ответ, но gitне может сообщить ядру, что оно хочет знать. Так что ему приходится все проверять самому (, хотя и делает он это довольно ловко ).
Основная идея здесь заключается в том, что все могло бы быть намного эффективнее, если бы API ядра -зависело от приложения. Но с точки зрения дизайна -это безумие, потому что существует так много разных приложений. Поддержание гораздо более широкого интерфейса ядра, вероятно, имеет сверх-линейную сложность. Но именно поэтому эффективность достигается за счет решения большего количества задач (для некоторых задач )в пользовательском -пространстве.