LINUX.ORG.RU
ФорумTalks

В Linux появился способ обойти системные вызовы, просто превратив процессы в библиотеки

 


0

7

Было 19 000 тактов. Стало 1 700. Это вообще нормально?

Инженеры Bytedance представили новый способ ускорения взаимодействия между процессами (IPC) в Linux, который они назвали RPAL — Run Process As Library («Запуск процесса как библиотеки»). Идея заключается в том, чтобы один процесс мог вызывать другой так, как будто это обычная функция в памяти, без участия ядра операционной системы. По их словам, это позволяет существенно повысить производительность и снизить нагрузку на CPU.

Классический IPC в Linux, включая сокеты и системные вызовы, часто становится узким местом в высоконагруженных системах. RPAL предлагает другой подход: минимизировать копирование данных, избегать переключений контекста ядра и при этом не требовать серьёзных изменений в коде приложений. По сути, это способ превратить отдельный процесс в библиотеку, которую можно вызвать напрямую, как обычную функцию.

Первичные тесты, проведённые Bytedance, показывают внушительный прирост производительности. В одном из экспериментов клиент передал миллион сообщений по 32 байта. При использовании обычного подхода на каждое сообщение тратилось в среднем 19 616 тактов процессора. С RPAL задержка снизилась до 1 703 тактов — это более чем 91% ускорения.

Кроме того, в реальных сценариях в дата-центре RPAL позволил снизить загрузку CPU до 15,5% за счёт уменьшения системных вызовов и более эффективного управления памятью. Особенно значимый вклад дала возможность делить адресное пространство между процессами, что сократило количество копий данных.

Однако у технологии есть ограничения. RPAL требует поддержки аппаратной функции Memory Protection Key (MPK), доступной на современных процессорах Intel и AMD Zen 4 и новее. Bytedance заявляет, что в будущем RPAL может работать и без MPK, но пока эта возможность только в планах.

Исходные патчи и RFC для внедрения RPAL уже опубликованы, и любой желающий может ознакомиться с кодом и предложениями Bytedance. Новая модель IPC выглядит как потенциальный шаг вперёд для Linux-систем, особенно в области высокопроизводительных микросервисов и систем реального времени.

https://www.securitylab.ru/news/558942.php

https://lore.kernel.org/lkml/CAP2HCOmAkRVTci0ObtyW=3v6GFOrt9zCn2NwLUbZ+Di49xkBiw@mail.gmail.com/

Кто-нибудь уже использовал?

Возможно ли создать шелл с поддержкой данной технологии?



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

просто превратив процессы в библиотеки

Решили перейти к архитектуре Windows 1.0 - 3.11 с глобальным адресным пространством и прямыми вызовами подсистем или как?

X512 ★★★★★
()

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

Я далек от ИБ, но разве это не будущий «meltdown/spectre» вырисовывается?

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

я все жду когда «зумеры» откроют для себя прямое обращение к видеопамяти, чтобы как в досовские времена «скриншот» из паскаля сохраняя 2д массив можно было делать :D

nerfur ★★★
()

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

It’s a neat idea and it is impressive that you got it running at all. But it’s a HUGE change in the process model and it’s obviously not generally applicable. You literally don’t have small processes any more. You only have big ones that are VERY expensive to tear down.

You’re basically suggesting completely tearing up process isolation in linux? This seems… unworkable? I’m really not hugely comfortable with the idea of essentially - changing how linux works - to get (suggested) better ipc latency?

Gary ★★★★★
()

От чего ушли ( dos ) к тому и возвращаемся. Ну а чего - если сейчас бесконечные апи абстракций над абстракциями для того, чтоб абстрагироваться от абстракций.

vtVitus ★★★★★
()

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

В Linux же всегда copy-on-write был на страницы памяти между процессами. Звучит как будто о какой-то другой ОС речь.

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

Ну в большинстве бэкенд кейсов изоляция процессов в хер не впилась.

bdrbt
()

Системные вызовы были придуманы не просто так от нефиг делать.

Я конечно не программист, но очень интересно как они в такой IPC собрались отлавливать исключения?

Допустим есть ядерный модуль который опрашивает ногу GPIO и возвращает ноль или единицу.

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

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

- - -

А если этот модуль будет инклудиться в гуе и дергаться какой-нибудь функцией типа int GetGPIOValue - что произойдет если эта функция посыпется, разделится на ноль, некорректно выделит память, в общем сегфолтнется? Весь гуй что ли уронится?

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

зумеры

Инженеры Bytedance

Это не просто «зумеры», это буквально тиктокеры, буквальнее некуда :)

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

Скрин это не интересно, а вот рисовать напрямую в видемопамять это вестч! :)

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

Решили перейти к архитектуре Windows 1.0 - 3.11 с глобальным адресным пространством и прямыми вызовами подсистем или как?

Зато появляться настоящие BSODы, а не то что сейчас... :)

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

вот видишь и простор для железных изменений появляется! скоро СПРАЙТЫ ЗАВЕЗУТ!)))

nerfur ★★★
()

Я ничего не понял, нот есть ли вариант что это можно будет использовать в контейнерах или виртуалках? Запуская там свои (микро)сервисы в виде той самой «библиотеки»?

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

shm но без копирования данных туда-сюда и вообще без ядра. Неясно зачем вообще напрягаться, херачили бы всё в один процесс сразу, включая ядро. Микросервисы какие-то напридумавали.

phoenix ★★★★
()

Я вот только не понимаю, зачем они гоняют ипц через ядро если могут просто скомпилить всё в один бинарь?

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

Подождём, пока инженеры Bytedance не откроют, что если не платить за покупки в магазине, то можно сэкономить до 90% зарплаты

buddhist ★★★★★
()
Ответ на: комментарий от ya-betmen

Я вот только не понимаю, зачем они гоняют ипц через ядро если могут просто скомпилить всё в один бинарь?

Ну дык это как раз тема в стиле «я познаю мир», чуваки открыли, что если не делать IPC, а скомпилить все в один бинарь, то выходит в 100500 раз быстрее)

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

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

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

полагаю из-за этого:

3. Application compatibility: Minimize the modifications to existing applications that utilize Unix domain sockets and the epoll() family.

To achieve the third target, RPAL stays compatible with the epoll family of functions, like epoll_create(), epoll_wait(), and epoll_ctl(). If an application uses epoll for IPC, developers can switch to RPAL with just a few small changes. For instance, you can just replace epoll_wait() with rpal_epoll_wait().

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

Плохо представляю себе хфт в котором эта шляпа была бы актуальна.

ya-betmen ★★★★★
()
Ответ на: комментарий от nerfur

прямое обращение к видеопамяти, чтобы как в досовские времена «скриншот» из паскаля

Сейчас такое уже может не сработать, потому что современные видеокарты хранят двухмерную графику в специальном тайловом формате, зависящем от вендора. См. dma-buf modifier.

Ещё этот способ делать скриншот очень медленный.

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

Так в микроядре Mach (в реализации как CMU, так и GNU) ядерный IPC ещё более слабое место в плане производительности, чем в Linux.

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

Ну давай запретим shared memory и vdso, если кому-то показалось что что-то вырисовывается

cobold ★★★★★
()

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

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

А мог бы просто поместить это в новости…

hobbit ★★★★★
()

Где на реальных задачах это применять? Где примеры с тестами популярного софта?

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

С моей колокольни (не очень в курсе что такие IPC), чтобы все эти микросервисы в отдельных контейнерах работали быстрее…

vitruss ★★★★★
()

...как будто это обычная функция в памяти, без участия ядра операционной системы.

Как это?

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

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

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

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

Посмотрел по ссылке, а там:

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

Для достижения второй цели RPAL опирается на общее адресное пространство для выполнения облегченного переключения контекста в пользовательском пространстве, которое мы называем «RPAL call». Это позволяет одному процессу выполнять код другого процесса так же, как как при вызове локальной функции.

Меня терзают смутные сомнения, что в случае если хоть один из таковых процессов засегфолтится, то перезагружать там, скорее всего, будет уже нечего да и незачем

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

Не вижу проблем в описанной windows10 ситуации.

MOPKOBKA ★★★★★
()

Сразу вопросы:

1) Вызываемая функция, вероятно, должна иметь доступ к каким-то данным процесса-библиотеки общим для всех приложений-клиентов. Но выполняется она в пространстве того, кто её вызвал. Как защититься от того, что процесс, который её вызвал попытается обратиться к памяти процесса-библиотеки напрямую? Даже без злого умысла это может случиться как минимум из-за какого-нибудь бага. А повреждение памяти процесса-библиотеки повалит другие процессы, так как эта память должна быть общей между всеми клиентами (иначе бы можно было бы сделать обычную библиотеку, а не процесс-библиотеку, если бы не было нужно разделяемое состояние).

2) Вызываемая функция выполняется в контексте процесса, который её вызвал. В вызываемой функции происходит сегфолт. Она валит вызвавший её процесс? А может ли она испортить вызвавшему процессу память?

Если забить на эти два вопроса, то без всяких изменений ядра можно просто компилировать все приложения в so (договориться об одной версии libc и товарищей, чтобы не было конфликтов) и грузить в один процесс (благо адресное пространство на 64 битах огромное). Но падать такой мега-процесс будет целиком, если что.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 2)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)