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

7 августа ровно в 11:00 по московскому времени тысячи игроков вспомнили, что такое очередь входа на сервер. А за неделю до этого увидели трейлер с, наверное, самым подходящим саундтреком для игры с огромным количеством разрушаемости.

Да, разумеется, речь идет о Battlefield 6, самом ожидаемом шутере этого года от огромной команды разработчиков во главе с Винсом Зампелла.

Я ворвался в бету ровно в 11 утра в день раннего доступа, стоически отстоял 150 тысяч человек в очереди, и отогнать меня от консоли с игрой было практически невозможно. И мне, как хардкорному фанату Call of Duty, есть что сказать.

Может ли ядро Linux при всей своей гибкости обеспечивать гарантированное время отклика при работе с приложениями?

Ядро Linux является универсальным и приспособлено к работе как с крошечными встраиваемыми устройствами, так и с титаническими серверами… а также со всем спектром машин между этими крайностями! Но может ли такое поразительно адаптивное ядро обеспечить гарантированную скорость отклика для приложения, работающего на всех этих платформах? Если в вашем приложении допустимая задержка при отклике укладывается в 200 микросекунд — то уверенно отвечаем на этот вопрос «да»! (Кстати, для Linux такая планка совсем не высока, но, чтобы её держать, потребуется тщательно подбирать аппаратное обеспечение и, возможно, обратиться за консультацией к специалисту по системам Linux, работающим в режиме реального времени).

Итак, почему же в приложении, работающем под Linux, иногда могут возникать задержки свыше 200 микросекунд? Универсальность ядра Linux требует сбалансировать пропускную способность, время отклика и честность распределения процессорной мощности, чтобы соответствовать требованиям такой универсальности. Если по одному из этих аспектов предъявляются жёсткие требования, то необходимо тонко настраивать как само ядро, так и поведение приложения. В этом посте рассмотрим 10 основных пунктов, которые необходимо учитывать при разработке системы Linux, к которой предъявляются строгие требования по работе в режиме реального времени. По каждому пункту также упомяну, в каком аспекте легко засыпаться разработчику-новичку, только приступающему к программированию систем реального времени под Linux.

Ссылки в Linux — это мощный инструмент, позволяющий указывать путь к файлам и каталогам. Существует два основных типа ссылок: жёсткие ссылки и мягкие ссылки (вторые также известны как символические ссылки или симлинки). Понимание различий между этими двумя типами поможет вам эффективно управлять файловой системой.

Поток — это последовательность элементов данных, предоставляемых за некоторое время. Концепция потока (stream) позволяет обрабатывать или передавать данные поэлементно, а не как одно целое. Потоки особенно полезны в сценариях, когда приходится работать с большими множествами данных, непрерывными данными или данными реального времени.

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

Ситуация на рынке ИТ-решений за последние годы изменилась — многие зарубежные вендоры ушли с российского рынка, что открыло новые возможности для отечественных разработчиков. Сегодня российские вендоры Service Desk утверждают, что не просто заменяют иностранные аналоги, но и предлагают уникальные преимущества: соответствие российскому законодательству, учёт местной специфики бизнес-процессов и техническую независимость. 

В обзоре рассмотрим самые ключевые вопросы при выборе Service Desk, оценим ключевые критерии выбора, задел которым дали иностранные решения и кратко пройдемся по основным вариантам на российском рынке.

За годы работы я подробно изучил, как центральные процессоры (CPU) выполняют код и как они устроены внутри. Дело в том, что я участвовал в разработке ядра Linux и ScyllaDB, а этот код очень близок к металлу. Я даже немного баловался с Verilog, безрезультатно попытавшись собрать моё собственное ядро RISC-V.

Графические процессоры (GPU) в отличие от обычных в основном оставались для меня чёрным ящиком, несмотря на то, что поработать с ними всё-таки довелось. Помню, что экспериментировал с NVIDIA RIVA 128 или чем-то подобным, проверяя, как там работает DirectX. Тогда такие процессоры ещё не выделялись на фоне ускорителей 3D-графики. Я также пытался идти в ногу со временем и немного упражнялся в программировании элементарных шейдеров на современных GPU. Но я никогда глубоко не вдавался в работу с GPU, и мои взгляды можно назвать CPU-центричными.

Однако, поскольку сегодня наблюдается всплеск рабочих нагрузок, связанных с ИИ, и, в частности, приходится работать с большими языковыми моделями (БЯМ), графические процессоры становятся незаменимыми для современных вычислений. К задачам, решаемым с применением ИИ, относятся масштабные прикладные тензорные операции, в том числе — сложение и перемножение матриц. А это уже работа для GPU. Но как современный GPU выполняет их, и насколько при этом возрастает эффективность по сравнению с выполнением таких же рабочих нагрузок на CPU?

В этой статье мы разберём, как написать программу для решения судоку. Предполагается, что ранее читатель не пробовал алгоритмически решать судоку, тем более — с применением нейронных сетей.

Однажды на работе техлид порекомендовал мне проштудировать книгу Understanding the Linux Kernel Бове и Чезати. В ней рассмотрена версия Linux 2.6, сильно не дотягивающая до более современной версии 6.0. Но в ней явно ещё много ценной информации. Книга толстая, поэтому на её изучение мне потребовалось немало времени. Занимаясь по ней, я решил настроить такую среду разработки, в которой я мог бы просматривать и изменять новейшую версию ядра Linux — чтобы было ещё интереснее.

Есть и другие статьи, в которых рассказано, как собрать ядро Linux. Но в этой статье я немного иначе организую и подаю информацию.

Многие компании сталкиваются с вопросом эффективной автоматизации бизнес-процессов и часто рассматривают BPM-системы как очевидное решение. Однако стоит ли полагаться на стандартизованную нотацию или лучше выбрать более гибкий путь? 

Меня зовут Иван Жигалов, и в этой статье мы разберемся, почему движение в сторону low-code-платформ приобретает все большую популярность среди предприятий, стремящихся к комплексной автоматизации бизнес-процессов.

При вызовах функций на языке С активно используется стек, который также именуется «стек вызовов». По мере того, как мы вызываем функции, они формируют так называемый «стек кадров». При каждом вызове функции образуется кадр, и эти кадры укладываются в стеке, где под них выделяется место. Далее в кадре из стека выделяется память под переменные и промежуточные значения. В кадре стека также содержится указатель на предыдущий кадр и значение счётчика команд. Та команда, которой оно соответствует, должна быть выполнена, как только кадр будет вытолкнут из стека. Далее давайте дизассемблируем вызовы функций в C, чтобы понять, как устроен стек кадров в ассемблере для ARM.

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

Некоторое время назад я написал несколько статей о различных трюках, применявшихся в операционной системе DOS, чтобы вписаться в те жёсткие лимиты памяти, которые действовали в реальном режиме на архитектуре x86. Постоянно возникал и оставался без ответа один вопрос: а каковы были различные «модели», которые предлагались компиляторами тех времён? Взгляните, как выглядело меню для генерации кода в Borland Turbo C++.

Tiny (крошечный), small (маленький), medium (средний), compact (компактный), large (большой), huge (огромный)… Что означают эти опции? Каковы их эффекты? Ещё важнее… а так ли важен весь этот антиквариат сегодня, в мире 64-разрядных машин и гигабайтных ОЗУ? Чтобы ответить на этот вопрос, сделаем небольшой обзор архитектуры 8086 и тех двоичных форматов, которые поддерживались в DOS.

Примерно с 2018 года я занимаюсь программированием инфраструктуры если не каждый день, то несколько раз в неделю. Я не утверждаю, что это позволяет мне претендовать на какой-то авторитет. Но за это время я определённо успел сформировать конкретные мнения по некоторым вопросам. В этой статье поделюсь некоторыми этими наблюдениями в качестве эмпирических правил, которым пытаюсь следовать при разработке для Terraform, но с тем же успехом вы можете применять их и в других языках для программирования инфраструктуры.

В этой статье мы разберём небольшой инструмент для трассировки системных вызовов. В отличие от strace и аналогов, здесь трассировка будет происходить внутри процесса, без применения ptrace() или эквивалентных вещей. Должен добавить, что это всего лишь демонстрационный пример, поэтому на практике он и близко не сравнится с strace. В частности, он пока не может точно выводить в консоль аргументы для большинства системных вызовов.

Именно на примере системных вызовов удобно продемонстрировать цепочную загрузку, и на то есть три причины...

В этой статье мы рассмотрим классический конкурентный кольцевой буфер и обсудим, как его можно оптимизировать для повышения производительности. Я покажу вам, как существенно улучшить этот показатель от 5,5 миллионов элементов в секунду до 112 миллионов элементов в секунду — и эти показатели выше, чем в реализациях Boost и Folly. Если вам требуется готовая реализация со всеми этими оптимизациями, посмотрите мою библиотеку SPSCQueue.h.

Кольцевой буфер также называется очередью «один производитель — один потребитель» (SPSC). В ней не бывает ожидания (и, соответственно, не бывает блокировок), это конкурентный примитив. Такая структура данных находит множество вариантов применения, и здесь я рассмотрю передачу сетевых пакетов между сетевым контроллером и драйверами операционной системы. Основная задача, решаемая при этом — выполнение событий ввода/вывода в относительно новом асинхронном API io_uring.

В настоящее время планировщик работы с ядрами ЦП, действующий в ядре Linux, предусматривает несколько режимов вытеснения. В этих режимах предлагается целый ряд компромиссов между временем отклика и пропускной способностью системы. Ещё в сентябре 2023 года развернулась дискуссия о работе планировщиков, в результате которой была выработана концепция «ленивого вытеснения». Данная концепция упрощает планирование задач в ядре, при этом улучшая результаты. Какое-то время эта работа протекала тихо, но затем ленивое вытеснение было заново реализовано Питером Зайлстрой в виде этой серии патчей. Притом, что сама концепция с виду работает хорошо, здесь ещё немало требуется доделывать.

Не кажется ли вам, что декларативная конфигурация и программирование инфраструктуры не так уж хороши, как их расхваливают?

Я достаточно долго занимался декларативной конфигурацией в Kubernetes: размышлял о ней, работал с kubectl apply, KRM, kustomize, Google Cloud Config Sync, kpt, porch, ... В то же время параллельно развивалась декларативная автоматизация — эта работа велась в Google, где на протяжении многих лет широко использовалась декларативная конфигурация. При этом вне Google появился Terraform, и на этом лоскутном одеяле также возникло множество других инструментов.

Что же такое декларативная конфигурация, в каких случаях она хороша, и как к ней подступиться?

GPU, также именуемый «видеокартой» или «графическим процессором» – это важнейший компонент компьютера, отвечающий за отображение картинок и видео. Графический процессор, в отличие от обычного ЦП (CPU), превосходно дробит задачи на подзадачи и распараллеливает их. В GPU всегда много ядер, поэтому вычисления на нём выполняются более эффективно. Поэтому GPU идеально подходит для многозадачности. В следующей таблице даётся упрощённое сравнение CPU и GPU.