Особенности работы кэша применительно к realtime на x86

    image В продолжение постов об использовании железа с х86 архитектурой в системах реального времени. Там я вкраце описал, насколько x86 удовлетворяют realtime требованиям, и что этому мешает.

    Небольшое лирическое отступление. Системы реального времени — один из наименее известных двигателей компьютерного прогресса. Например, первый портативный компьютер был создан благодаря им. Сейчас почему-то считается, что первым серийным портативным компьютером был Osborn. На самом деле устройство на картинке выше было создано в Сименсе как cредство управления и программирования промышленной автоматизации за два года до Osborn. Переносные компьютеры этого семейства (Siemens Simatic) выпускаются и сейчас, хотя, конечно, железо много раз менялось.

    Но перейдем к делу. В этом топике я подробнее остановлюсь на одном из факторов, который мешает предсказуемости времени выполнения realtime кода. Под катом будет не длинный, но нудноватый текст.

    Эффективное использование кэша полезно большинству ворклоадов, не только для realtime. Очень жизненный пример — на одном ядре работает код, который просыпается раз в миллисекунду, опрашивает датчики, исполняет PLC код, управляет какой-то железкой. Одновременно на другом ядре работает код ГУИ, который все это отображает на мониторе и позволяет оператору иногда вмешиваться. Современный ГУИ достаточно «толстый», и с удовольствием использует весь доступный кэш, который, кстати, общий с первым ядром. Так что когда риалтайм код просыпается, никаких своих данных в общем кэше он не найдет — придется тащить заново из памяти, тратя десятки или сотни микросекунд.

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

    1. PREFETCHx — вытащить линию из памяти в кэш заренее
    2. CFLUSH, WBINV(Очень «злая» команда, кстати) — «обнулить» линию или весь кэш
    3. non temporal COVNTDQ/MOVNTDQA/MOVNTPS, ordering control (L/S/MFENCE) — управление кэшируемостью некоторых операций с данными
    4. Всякие косвенные способы. Здесь я имею в виду хитрые способы хранения и доступа к данным, например, более дружественные префетчерам
    5. Прямая запись в кэш через ДМА. Эта не очень популярная фича актуальна для производителей периферии.
    Можно кэш вообще отключить, но это как-то слишком экстремально.

    Как видите, среди этих способов нет ничего похожего, например, на cache lockdown — фичу, которая есть в ARM, или аналогичные возможности MIPS. Зарезервировать кусочек кэша бывает полезно дла разработчиков realtime кода, например, в случае, описанном выше. Не исключено, что когда-нибудь и в х86 появится нечто похожее, хотя это и противоречит идеологии прозрачной работы памяти. Но пока можно воспользоваться паллиативом.

    image

    На картинке видно, что у физического адреса и адреса в кэше есть общие 5 бит. Ну, так получилось — просто повезло. Это позволяет «покрасить» физическую память постранично в 32 цвета. Зачем? Ядро ОС при создании адресного пространства для приложения тогда может отдавать ему виртуальную память только одного цвета. Если давать основным потребителям кэша память разных цветов, то их данные не смогут вытеснять друг друга из кэша.

    В примере, приведенном выше очевидно, что если выделять обоим задачам память разного цвета, проблема будет решена. ГУИ достанется меньше кэша, но очень вероятно, что оператор никаких тормозов не заметит. Есть, конечно, один большой недостаток — речь может идти только о виртуальной памяти, и если что-то в ядре тоже хочет много кэша, то ничто не сможет ему помешать.

    Этот же метод используется в ядрах Windows и FreeBSD, чтобы более равномерно распределять память в по сетам в ассоциативном кэше. При низкой ассоциативности кэша это достаточно важно для того, чтобы никакой его кусочек не пропал зря. Чтобы использовать этот подход, от программиста ничего не требуется — все делает ОС. Но ни в одной production ОС сейчас не используется раскраска кэша для разделения данных процессов, есть только неофициальные патчи.

    Ну и кстати всем разработчикам realtime на x86 желаю не забывать отключать C-states и Speedstep.

    Кстати, если кто знает русскую замену всяким англицизмам, которые я использовал в топике — пожалуйста, дайте знать в комментариях, а я поправлю в тексте.
    Intel
    202,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 25

      +2
      Расскажите про работу с кэшем в сравнении двух архитектур ARM и x86.
        0
        Про работу с кэшем или работу кэша? Про работу с кэшем на х86 я написал выше в 5 пунктах, вы имеете в виду, что надо написать подробнее и добавить про Arm?
          0
          Добавить про Arm. Интересуют различия двух архитектур.
            +1
            ОК, то есть надо писать новый пост. Попробую.
        0
        «на одном ядре работает код, который просыпается раз в миллисекунду, опрашивает датчики, исполняет PLC код, управляет какой-то железкой. Одновременно на другом ядре работает код ГУИ»

        разве не только L3-кеш расшарен, но и L2/L1?
        сомнительно, наверно всё же у каждого ядра свой кеш.

        «cache lockdown» — запирание кеша?
          +1
          L1/L2 конечно у каждого ядра свои (если ядра настоящие, не HT) Но если бы в них все помещалось, L3 был бы не нужен.

          С «запиранием кэша» есть только одна проблема — если кто-то захочет найти в Армовской документации, что такое cache lockdown — не проблема. А чтобы найти «запирание кеша», надо сначала правильно перевести на английский.
          0
          У Core2Duo L2 расшарен. У AMD x2 — был у каждого свой.
          Интел писали «но если что то ядру доступно больше кэша»
            0
            Многим бенчмарков общий кэш полезен. Некоторым, включая realtime — вреден.
              0
              Ну я это и имел в виду — зависит от задач. Если простое однопоточное приложение — то Интел лучше. Если многопоточное — АМД.
                +3
                В общем случае ответ сложнее. У обоих подходов есть плюсы и минусы. Например, в примере выше, если бы улучшение производительности ГУИ было бы важнее, чем потенциальные задержки в выполнении PLC кода, общий кэш был бы эффективнее.
          0
          1. Не так уж и много в промышленности процессов, где требуются циклы опроса в миллисекунду или около того.
          2. Там, где всё-таки оно нужно, никакого GUI и вообще многозадачности на процессоре не крутится. К тому же, x86 там встречается тоже редко.
            +1
            1. У меня лично сейчас главная задача — использовать x86 там, где циклы опроса — 100 микросекунд.
            Год назад один из немецких производителей пром контроллеров показывал на конференциях, как с x86 при сниженее цикла опроса с миллисекунды в 2 раза на каждой пластиковой бутылочке экономилось под 10% пластика.
            2. Beckhoff, Tenasys, Windriver успешно и давно продают софт и контроллеры с Windows GUI, realtime и многозадачностью. Некоторые делают тоже для себя, или Linux решения.
              0
              А кассовые аппараты с Embedded Windows — это realtime системы?
                0
                soft realtime, наверное. там кассир не заметит если что-то не так, и если система не успеет просканировать код — еще раз пронесет товар над сканером.
                  +2
                  Кассовый аппарат и сканер штрих-кодов это разные устройства.
                    0
                    ок, я не эксперт в POS агрегатах
                  0
                  А где вы видели такие аппараты? Сейчас в основном кассы работают под DOS, Linux или Windows. В последнем случае это несколько урезанная версия Windows XP, в которой кассовая программа работает как обычное приложение (например, на .net framework), а девайсы все подключены через обычный OPOS-совместимый windows-драйвер.
                    0
                    Хм… аж под 80% рынка POS терминалов занимает Windows Embedded, хотя что-то могло и измениться… Но у нас в Нижнем все крупные супермаркеты работают именно на таких.
                      0
                      Наврал, наврал, посыпаю голову пеплом. Это похоже суммарная доля всех Win терминалов. Но Spar точно использует версии на Embedded. Надо будет изучить эту тему.
                  0
                  1. То есть у нихдо этого был неэффективный способ управления? Или они изменили тех. процесс?
                  Просто от времени отклика пластик экономиться не будт.
                    0
                    изменили только контроллер, станок остался тот же.
                0
                > Вообще, архитектура х86 предоставляет не очень много
                > возможностей программного управления работой кэша.
                > Перечислю все эти способы, как раз хватит пальцев на одной руке:

                При условии, что у вас на руке два безымянных пальца (два пункта в списке имеют номер 4).
                  0
                  Спасибо за багрепорт.
                  Cut&paste — зло. Оставить что-ли так, для прикола?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое