• Современная операционная система: что надо знать разработчику

      Александр Крижановский (NatSys Lab.)


      Александр Крижановский

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

      По моему мнению, современная ОС – это плохая штука.




      Дело в том, что на картинке изображены графики сайта Netmap (это штуковина, которая позволяет вам очень быстро захватывать и отправлять пакеты сетевого адаптера), т.е. эта картинка показывает, что на одном ядре с разной тактовой частотой до 3 ГГц Netmap позволяет 10 Гбит – 14 млн. пакетов в сек. отрабатывать уже на 500 МГц. Синенькая линия – это pktgen – самое быстрое, что, вообще, есть в ядре Linux’а. Это такая штуковина – генератор трафика, который берет один пакет и отправляет его в адаптер много раз, т.е. никаких копирований, никакого создания новых пакетов, т.е., вообще, ничего – только отправка одного и того же пакета в адаптер. И вот оно настолько сильно проседает по сравнению с Netmap (то, что делается в user-space показано розовой линией), и оно вообще где-то там внизу находится. Соответственно, люди, которые работают с очень быстрыми сетевыми приложениями, переезжают на Netmap, Pdpdk, PF_RING – таких технологий море сейчас.
      Читать дальше →
    • Трёхмерная графика с нуля. Часть 2: растеризация

      • Перевод
      image


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

      К сожалению, эта простота имеет свою цену: низкую производительность. Несмотря на то, что существует множество способов оптимизации и параллелизации трассировщиков лучей, они всё равно остаются слишком затратными с точки зрения вычислений для выполнения в реальном времени; и хотя оборудование продолжает развиваться и становится быстрее с каждым годом, в некоторых областях применения необходимы красивые, но в сотни раз быстрее создаваемые изображения уже сегодня. Из всех этих областей применения самыми требовательными являются игры: мы ожидаем рендеринга отличной картинки с частотой не менее 60 кадров в секунду. Трассировщики лучей просто с этим не справятся.

      Тогда как это удаётся играм?

      Ответ заключается в использовании совершенно иного семейства алгоритмов, которое мы исследуем во второй части статьи. В отличие от трассировки лучей, которая получалась из простых геометрических моделей формирования изображений в человеческом глазе или в камере, сейчас мы будем начинать с другого конца — зададимся вопросом, что мы можем отрисовать на экране, и как отрисовать это как можно быстрее. В результате мы получим совершенно другие алгоритмы, которые создают примерно похожие результаты.
      Читать дальше →
      • +36
      • 9,2k
      • 2
    • Обзор примитивов синхронизации — спинлоки и тайны ядра процессора

        Последняя статья про классические примитивы синхронизации.

        (Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

        Сегодня мы немножко заглянем в процессор. Чуть-чуть.

        По сути, мы будем говорить про единственный примитив, который принципиально отличается от остальных: спинлок. Spinlock.

        В комментариях к предыдущим заметкам возникла дискуссия — насколько справедливо вообще выделять спинлок как примитив, ведь по сути он — просто мьютекс, верно? Он выполняет ту же функцию — запрещает одновременное исполнение фрагмента кода несколькими параллельными нитями.

        На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

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

        Дело в том, что внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

        Есть и ещё одно, семантическое различие. Мьютекс допускает и предполагает снятие нити с процессора, долгую остановку вызывающей нити. Мьютексом можно запереть объект на час или сутки, это приемлемо и нормально. Спинлок принципиально рассчитан только на кратчайшие приостановки, это всегда работа с неатомарным стейтом объекта. Присваивание группы переменных, небольшой цикл — это максимум того, что можно сделать под спинлоком.

        Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

        Как устроен спинлок?
        Читать дальше →
      • Пишу игрушечную ОС (о реализации мьютекса)


          Продолжаю блог о разработке игрушечной ОС (предыдущие посты: раз, два, три). Сделав паузу в кодировании (майские праздники, всё-таки), продолжаю работу. Только что набросал сканирование PCI-шины. Эта штука понадобится для работы с SATA-контроллером: следующее, что хочу сделать — это простенький драйвер диска. Он позволит поэкспериментировать с проецированием постоянной памяти на адресное пространство (своппинг, доведённый до логического конца). А пока хотел бы описать реализацию мьютекса.
          Читать дальше →
        • Профилирование кода на C/С++ в *nix-системах



            Александр Алексеев (Postgres Professional)


            Отличный обзорный доклад конференции HighLoad++ 2016 о том, как надо проводить профилирование программного кода. О типичных ошибках, происходящих при измерениях. И, конечно, об инструментах:

            — gettimeofday
            — strace, ltrace, truss
            — gprof
            — gdb / lldb
            — perf
            — pmcstat
            — SystemTap
            — DTrace
            — HeapTrack
            — BPF / bcc

            image

            В начале у меня будет не слишком техническая часть, о том, как не надо делать benchmark’и.

            Я наблюдаю, что люди часто делают типичные ошибки, когда делают benchmark’и. И вот первая из них…
            Читать дальше →
            • +19
            • 7,2k
            • 2
          • Как работает Android, часть 1


              В этой серии статей я расскажу о внутреннем устройстве Android  —  о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.

              Читать дальше →
            • Прокачиваем USB Mass Storage Device на STM32F103 с помощью FreeRTOS и DMA

                image
                Недавно я ковырялся с подключением своего устройства на микроконтроллере STM32F103 как USB Mass Storage Device, или по русски — как флешку. Вроде бы как все относительно несложно: в графическом конфигураторе STM32CubeMX в пару кликов сгенерировал код, добавил драйвер SD карты, и вуаля — все работает. Только очень медленно — 200кбайт/с при том, что пропускная способность шины USB в режиме Full Speed гораздо выше – 12 мБит/с (грубо 1.2 Мбайт/с). Более того, время старта моей флешки в операционной системе составляет около 50 секунд, что попросту некомфортно в работе. Раз уж я нырнул в эту область, то почему бы и не зачинить скорость передачи.

                Вообще-то я уже писал свой драйвер для SD карты (точнее драйвер SPI), который работал через DMA и обеспечивал скорость до 500кб/с. К сожалению в контексте USB этот драйвер не заработал. Причиной всему сама модель общения USB — там все делается на прерываниях, тогда как мой драйвер был заточен под работу в обычном потоке. Да еще и припудрен примитивами синхронизации FreeRTOS.

                В этой статье я сделал парочку финтов, которые позволили выжать максимум из связки USB и SD карточки подключенной к микроконтроллеру STM32F103 по SPI. Также тут будет про FreeRTOS, объекты синхронизации и общие подходы к передаче данных через DMA. Так что, думаю, статья будет полезна и тем кто только разбирается в контроллерах STM32, и инструментах вроде DMA, и подходах при работе с FreeRTOS. Код построен на основе библиотек HAL и USB Middleware из пакета STM32Cube, а также SdFat для работы с SD картой.
                Читать дальше →
              • Настройка IDE Clion и Cmake для работы с STM32 и C++

                Перед примером моей настройки немного лирики.

                Давно хотел попробовать себя в микроконтроллерах, вернее были идеи с их использованием, которые очень хотелось реализовать. Сначала начал с PIC32 — огонь контроллеры. Так получалось, что поначалу и коротил их порты, и с питанием завышал — неубиваемые (не совсем конечно, порт правда однажды сгорел, но сам контроллер продолжал работу). IDE MplabX неплоха, подкупал графический блок с отображением занимаемой RAM/Flash на выбранном МК — удобно, но сам NetBeans как IDE это жесть, ну не удобно ни разу после Idea. Но проблема была не в этом — как потом оказалось, PIC'и тяжело достать, мало кто их возит, а если и возит, то по относительно высокой цене.

                Дальше решил копнуть в сторону STM32 — они в больших количествах, за базовую периферию просят не много, но главное — это доставаемость. (Но кодогенератор STM'а хуже Microchip'a — весь файл загажен комментами и функциями, это конечно сильно огорчило. У Microchip'а все сгенеренные функции вынесены в отдельные файлы и main.c практически чист — прелесть).
                (UPD: вот тут признаюсь ошибался, спасибо golf2109, он подсказал, что от заваливания комментами и функциями файла main.c можно избавиться, достаточно включить в настройках опцию для вынесения сгенерированного кода в отдельные файлы, но я все же в недоумении, почему это не дефолтная настройка, вроде логично было бы)

                Теперь об IDE для STM32.
                Читать дальше →
              • Планетарный ландшафт

                • Tutorial
                Трудно поспорить, что ландшафт — неотъемлемая часть большинства компьютерных игр на открытых пространствах. Традиционный метод реализации изменения рельефа окружающей игрока поверхности следующий — берем сетку (Mesh), представляющую из себя плоскость и для каждого примитива в этой сетке производим смещение по нормали к этой плоскости на значение, конкретное для данного примитива. Говоря простыми словами, у нас есть одноканальная текстура размером 256 на 256 пикселей и сетка плоскости. Для каждого примитива по его координатам на плоскости берем значение из текстуры. Теперь просто смещаем по нормали к плоскости координаты примитива на полученное значение(рис.1)


                Рис.1 карта высот + плоскость = ландшафт

                Почему это работает? Если представить, что игрок находится на поверхности сферы, и радиус этой сферы чрезвычайно велик по отношению к размеру игрока, то искривлением поверхности можно пренебречь и использовать плоскость. Но что если не пренебрегать тем фактом, что мы находимся на сфере? Своим опытом построения такого рода ландшафтов я хочу поделиться с читателем в данной статье.
                Читать дальше →
              • CDC+MSC USB Composite Device на STM32 HAL

                • Tutorial
                image

                Мне хотелось бы верить, что хотя бы половина читателей может расшифровать хотя бы половину названия статьи :) Кто не в курсе — поясню. Мое устройство должно реализовывать сразу две USB функции:

                • Mass Storage Device (он же Mass Storage Class — MSC). Я хочу, чтобы мой девайс прикидывался обычной флешкой и отдавал файлики с данными, которые лежат на SD карте.
                • Другая функция это виртуальный COM порт (он же в терминологии USB называется Communication Device Class — CDC). Через этот канал у меня идет всякий дебажный вывод, который удобно смотреть обычным терминалом.

                В большинстве примеров по работе с USB реализуется только один тип устройства — флешка, мышка, кастомное HID устройство или виртуальный COM порт. А вот найти вменяемое объяснение как реализовать хотя бы две функции одновременно оказалось не так просто. В своей статье я хотел бы восполнить этот пробел.

                Я буду описывать создание композитного USB устройства на базе микроконтроллера STM32, но сам подход будет также применим и для других микроконтроллеров. В статье я детально разберу каждый из классов по отдельности, так и принцип построения композитных устройств. Но обо все по порядку.

                Итак, поехали!
                Читать дальше →