Итак, финал части 1! По крайней мере основного разбора без дополнений. Собственно, сегодня мы разберем то, чем в основном с точки зрения ядра ОС и CPU являются все вот эти ваши бэкенды – системные вызовы и всё, что вокруг них.

На самом деле механизм немного замудренный и “в лоб” сразу все эти системные вызовы мы разбирать не будем, потому что вокруг них существует ещё несколько концепций.

Итак, начнем!

User mode, Kernel mode

Процессор исполняет код в разных уровнях привилегий.

Это механизм защиты, который не позволяет пользовательским программам напрямую управлять системой. Зачем? Для безопасности. Чтобы чей-нибудь опасный ассемблерный вайбкод случайно всё не поломал!

Да и вообще, если бы любая программа могла выполнять любые инструкции CPU, она могла бы:

Читать память других процессов
Управлять устройствами
Изменять таблицы страниц
Выключать систему

Чтобы этого не происходило, CPU разделяет код по уровням доступа.

Хотя в архитектуре x86 существует 4 уровня привилегий:

Ring 0 – kernel mode

Ring 1 – драйверы

Ring 2 – системные службы и файлы

Ring 3 – user mode

По факту, Ring 1 и Ring 2 – это легаси, которое Американские деды проектировали с научной красотой, но без реальной производственной необходимости. В реальной жизни используются только 2 уровня – Ring 0 и Ring 3 для бОльшей совместимости софта с другими ОС, упрощения поддержки, да и вообще переключение уровней доступа дорогое(100-150 тактов CPU), соответственно, чем больше колец, тем хуже производительность.

Получается, что

В user mode выполняется обычный код программ.

Например:

Браузер
База данных
Go runtime
CLI утилиты
Ваш вайбкод

В этом режиме запрещены инструкции, которые могут повлиять на систему.

Например:

Управление устройствами
Изменение page tables
Управление прерываниями
Прямой доступ к физической памяти

Если программа попытается выполнить такую инструкцию, CPU сгенерирует exception(если что, это аппаратное прерывание).

В свою очередь, в kernel mode выполняется код операционной системы.

Здесь доступны все инструкции процессора.

Ядро может:

Управлять памятью
Планировать потоки
Работать с драйверами устройств
Управлять файловой системой
Обрабатывать сетевые пакеты

Kernel mode обладает полным контролем над системой.

А теперь внимание!!!

Переход из user mode в kernel mode выполняется через системный вызов.

На x86-64 используется инструкция:

syscall

Давайте зафиксируем:

Системный вызов (system call) – обращение прикладной программы к ядру операционной системы для выполнения какой-либо операции.

Системные вызовы

Теперь рассмотрим более детально, что вообще происходит в этот момент.

Инструкция означает для процессора (CPU core), следующую последовательность действий

Переключить CPU в kernel mode
Передать управление ядру
Выполнение операции

После завершения происходит возврат:

sysret

Но, я уже понимаю, что возникают 2 вопроса: “Что значит “Передать управление ядру”?” и “Что ядро вообще должно исполнять?”

Давайте по порядку. Передача управления ядру происходит следующим образом:

CPU переключается из Ring 3 в Ring 0
Переключается на kernel stack
Загружается точка входа в kernel
Управление передается обработчику системного вызова

В Linux x86-64 используется соглашение:

RAX – номер syscall

RDI – arg1

RSI – arg2

RDX – arg3

R10 – arg4

R8 – arg5

R9 – arg6

Это по сути аргументы системного вызова, которые именно вы и передаете

Что происходит после перехода в kernel mode?

Сохранение контекста процесса
По номеру системного вызова из RAX ядро находит обработчик в таблице sys_call_table
Выполнение операции

Инструкция syscall сохраняет адрес возврата в специальный регистр RCX(То есть RIP → RCX) и RFLAGS в R11, когда ядро закончит работу, инструкция sysret возьмет этот адрес и вернет процессор обратно в Ring 3 к вашей следующей строчке кода!

А что вообще за обработчики?

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

Например, для x86:

IA32_LSTAR – точка входа для системного вызова

IA32_STAR – сегменты перехода

IA32_FMASK – маска флагов

А номера системных вызовов?

Это просто соответствия, которые также загружаются нашей ОС. Например для linux можете посмотреть тут. 100% большинство из них узнаете!

А теперь давайте посмотрим путь ~~самурая~~ системного вызова

Есть код в Go:

package main

import (
	"syscall"
)

func main() {
	msg := []byte("Yo bro!!!!\n")

	syscall.SyscallN(
		1,
		uintptr(1),
		uintptr(unsafe.Pointer(&msg[0])),
		uintptr(len(msg)),
	)
}

// func SyscallN(trap uintptr, args ...uintptr) (r1, r2 uintptr, err Errno)

/*
trap → номер системного вызова
args → аргументы, которые полетят в системный вызов
trap = 1 = write(linux)
args[0] = 1
args[1] = указатель на буфер
args[2] = длина
*/

Внутри Go runtime вызывается asm-функция.

Для Linux x86-64 она выглядит примерно так:

MOVQ trap+0(FP), AX
MOVQ args+8(FP), DI
MOVQ args+16(FP), SI
MOVQ args+24(FP), DX
SYSCALL

Перед syscall:

RAX = номер системного вызова

RDI = arg1

RSI = arg2

RDX = arg3

То есть в нашем случае

RAX = 1

RDI = 1

RSI = &msg[0]

RDX = 11

Теперь что делает CPU:

Когда выполняется SYSCALL

Процессор

Переключается из Ring 3 → Ring 0
Сохраняет RIP в RCX
Сохраняет RFLAGS в R11
Загружает точку входа в kernel

Эта точка входа хранится в MSR:

IA32_LSTAR

Linux получает управление в entry_SYSCALL_64

Файл:

arch/x86/entry/entry_64.S

Дальше вызывается do_syscall_64

А теперь само ядро:

Ядро читает:

RAX = номер системного вызова и находит точку входа в обработчик в таблице.Для write это sys_write.

После чего обращаясь к драйверу терминала(если stdout) или файловой системы производим запись и далее sysret!

Разобрали только для Linux. Для Mac или Windows делать мы этого не будем, потому что получится долго и по большей части бессмысленно из-за похожести механизма по своему принципу!

Дороговизна системных вызовов и удешевление

Если возникает вопрос, дорого ли это?

Краткий ответ – да и еще раз да.

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

Само по себе переключение режима тоже чего-то да стоит. 100-150 тактов, как я ранее указал. Но помимо этого происходит также следующее:

Системный вызов действует как полный барьер памяти
Сохранение контекста(уже в самом коде ядра)
RIP → RCX, RFLAGS → R11
Остановка и перестройка пайплайна обработки команд(для обработки уже системного вызова)
Cache miss для команд и памяти(как правило)

И это только на вызове!!!

А после sysret

Переключается уровень доступа
Опять переключается контекст
Опять перестраивается пайплайн

Соответственно, стоимость системного вызова БЕЗ взаимодействия с устройством(например, принтером) – это где-то 150-400 циклов, а если взаимодействовать и с ними, то это может обойтись в несколько тысяч!

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

Буферизация

В Go например это будет выглядеть так:

w := bufio.NewWriter(os.Stdout)

w.WriteString("hello")

w.WriteString("guys")

w.Flush()

То есть реальный системный вызов только при w.Flush() и вместо двух write операций, мы получили одну!

Batch-операции

Некоторые системные вызовы позволяют передать сразу несколько операций.

К примеру:

writev
readv
sendmsg
recvmmsg

Вместо:

write

write

write

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

И уменьшить количество переходов user → kernel

epoll

Если сервер работает с тысячами соединений, наивный подход выглядел бы так:

read(socket1)

read(socket2)

read(socket3)

Но большинство сокетов в данный момент ничего не имеют для чтения.

Каждый read – системный вызов. Представили боль CPU?

epoll решает проблему:

Программа регистрирует сокеты в ядре ОС в специальной структуре данных, которая является красно-черным деревом(для файловых дескрипторов) с помощью epoll_ctl. Дерево помогает быстро искать по файловым дескрипторам.
Ядро отслеживает события. То есть когда на сетевую карту что-то приходит, она создает аппаратное прерывание, а после чего драйвер сетевой карты передает в буфер конкретного сокета данные, как только данные приходят, срабатывает обработчик, с помощью которого сокет помещается в двусвязный список готовых событий(ReadyList).
Приложение спрашивает, у кого есть данные. С помощью системного вызова epoll_wait программа получает доступ к готовым нужным ей событиям из Ready List, то есть ядро ОС копирует информацию о готовых событиях из этого самого списка!

Да, к слову, наш любимый netpoller из Go Scheduler точно так же использует данный системный вызов!

mmap

Иногда повторные системные вызовы можно вообще убрать.

Например, обычное чтение файла:

read(fd, buffer)

Каждое чтение требует системного вызова.

А mmap делает иначе:

файл отображается в память процесса

После этого чтение файла выглядит как обычный доступ к памяти

Zero-copy

Некоторые системные вызовы позволяют не копировать данные между user space и kernel space.

Например:

sendfile

splice

Обычный путь:

диск → kernel → user → kernel → сокет

sendfile делает:

диск → kernel → сокет

Без копирования в user space.

Думаю, необходимые механизмы и нюансы работы CPU(и даже частично операционной системы) мы разобрали, теперь пойду выйду из подвала, прогуляюсь и начнем уже разбирать непосредственно Go! Настоятельно рекомендую пробежаться по всей части целиком. Вот ссыль на первую статью.

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

Деконструкция GO: CPU, RAM и что там происходит. Системные вызовы. Часть 1.5