Монополизирующие процессорные наборы

Если процессорный набор помечен как cpu_exclusive или mem_exclusive, то ни один другой процессорный набор, отличный от прямого предка или потомка, не может совместно использовать те же ЦП или узлы памяти.

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

Hardwall

Процессорный набор, у которого установлен флаг mem_exclusive или mem_hardwall считается hardwall. Процессорный набор hardwall ограничивает выделение памяти ядром под страницы, буфер и другие данные, часто используемые ядром для нескольких пользователей. Все процессорные наборы, hardwall или нет, ограничивают выделение памяти для пространства пользователя.

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

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

Уведомление об освобождении

Если в процессорном наборе установлен флаг notify_on_release (1), то когда последний процесс в процессорном наборе выходит (завершается или прикрепляется к другому процессорному набору) и последний потомок этого процессорного набора удаляется, то ядро выполняет команду /sbin/cpuset_release_agent, передавая ей путь (относительно точки монтирования файловой системы процессорного набора) ликвидируемого процессорного набора. Это включает автоматическое удаление ликвидируемых процессорных наборов.

Значение по умолчанию notify_on_release в корневом процессорном наборе при запуске системы сброшено (0). Значение по умолчанию в других процессорных наборах при создании равно текущему значению notify_on_release их предка.

Вызываемой команде /sbin/cpuset_release_agent в argv[1] передаётся имя (относительно пути /dev/cpuset) освобождаемого процессорного набора.

Обычно, команда /sbin/cpuset_release_agent — простой сценарий оболочки:

#!/bin/sh
rmdir /dev/cpuset/$1

Для сброса и установки, как и других флагов, этот флаг можно изменить, записав в файл ASCII-номер 0 или 1 (с необязательным символом новой строки в конце), соответственно.

Нагрузка памяти

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

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

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

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

Если вычисление нагрузки памяти не включено в псевдо-файле /dev/cpuset/cpuset.memory_pressure_enabled, то она не вычисляется для всех процессорных наборов, и чтение из любого файла memory_pressure всегда возвращает ноль в виде строки ASCII «0\n». Смотрите раздел ПРЕДУПРЕЖДЕНИЯ далее.

Для каждого процессорного набора скользящее среднее (running average) используется по следующим причинам:

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

Значение memory_pressure для процессорного набора вычисляется с помощью индивидуального простого цифрового фильтра, который хранится в ядре. Для каждого процессорного набора этот фильтр отслеживает недавний уровень, с которым процессы, прикреплённые к этому процессорному набору, использовали код непосредственного освобождения ядром (kernel direct reclaim code).

Код непосредственного освобождения ядром выполняется, когда процессы из-за нехватки готовых свободных страниц удовлетворяют запрос выделение страницы памяти приспособлением (repurpose) страницы, занятой под другие цели. Грязные страницы файловой системы приспосабливаются после первой записи обратно на диск. Неизменённые страницы буфера файловой системы приспосабливаются простым сбросом, и если такая страница потребуется снова, то она будет повторно прочитана с диска.

Файл cpuset.memory_pressure содержит целое число, представляющее недавний (период спада (half-life) за 10 секунд) уровень записей в код непосредственного освобождения, вызванный любым процессом в процессорном наборе, выражаемый в количестве освобождений в секунду, умноженном на 1000.

Распространение в памяти

Для каждого процессорного набора есть два файла — логических флага, которые управляют местом, где ядро выделяет страницы для буферов файловой системы и других структур данных ядра. Они называются cpuset.memory_spread_page и cpuset.memory_spread_slab.

Если установлен индивидуальный логический флаг-файл cpuset.memory_spread_page, то ядро будет распространять буферы файловой системы (страничный кэш) последовательно по всем узлам, которые разрешено использовать процессу, а не располагать эти страницы на узле, на котором выполняется процесс.

Если установлен индивидуальный логический флаг-файл cpuset.memory_spread_slab, то ядро будет распространять slab-кэши файловой системы, например, для записей inode и каталогов, последовательно по всем узлам, которые разрешено использовать процессу, а не располагать эти страницы на узле, на котором выполняется процесс.

Установка этих флагов не влияет на страницы сегмента данных (смотрите brk(2)) или стека процесса.

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

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

Из-за настройки распространения в памяти при выделении страниц или кэшей slab происходит игнорирование политики памяти NUMA процесса и задействуется распространение. Однако, эффект этих изменений по расположению в памяти, вызванный указанным в процессорном наборе распространением в памяти скрыт, от вызовов mbind(2) или set_mempolicy(2). При работе с данными вызовами политики памяти NUMA кажется, что они всегда ведут себя как-будто распространение в памяти согласно процессорному набору не действует, даже если это не так. Если распространение в памяти согласно процессорному набору затем выключить, то автоматически повторно применится политика памяти NUMA, заданная этими вызовами последней.

Файлы cpuset.memory_spread_page и cpuset.memory_spread_slab хранят логический флаг. По умолчанию, они содержат «0»; это означает, что данное свойство в процессорном наборе выключено. Если в файл записать «1», то это включит данное свойство.

Распространение в памяти, указанное в процессорном наборе, похоже (в других контекстах) на циклический алгоритм или размещение памяти чередованием.

Распространение в памяти, указанное в процессорном наборе, может существенно повысить производительность заданий, которым:

1.

Необходимо разместить локальные данные нити в узлах памяти близко к ЦП, на которых выполняются нити, то есть наиболее наиболее востребованные данные;

2.

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

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

Перенос памяти

Обычно, при настройке cpuset.memory_migrate по умолчанию (выключена) как только страница выделена (получена физическая страница в основной памяти), она остаётся на узле, на котором выделена до тех пор, пока остаётся выделенной, даже если в дальнейшем изменяется политика процессорного набора mems по размещению в памяти.

При включённом переносе памяти в процессорном наборе, если значение mems в процессорном наборе изменяется, то если страница памяти, используемая любым процессом в процессорном наборе, становится расположенной в запрещённом узле, то эта страница перемещается в разрешённый узел памяти.

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

Если возможно, при операции перемещения относительное размещение перемещаемых страниц в процессорном наборе сохраняется. Например, если страница была на втором разрешённом узле в предыдущем процессорном наборе, то страница будет помещена на второй допустимый узел нового процессорном наборе, если возможно.

Балансировка нагрузки планировщиком

Планировщик ядра автоматически балансирует нагрузку, вызываемую процессами. Если один ЦП недозагружен, то ядро будет искать процессы на других, более загруженных ЦП и переместит процессы на недозагруженный ЦП, с учётом ограничений механизмов размещения в процессорных наборах и sched_setaffinity(2).

Траты на алгоритм балансировки нагрузки и его влияние на основные совместно используемые структуры данных ядра, такие как список процессов, с ростом балансируемых ЦП увеличиваются больше, чем линейно. Например, затраты на него больше при балансировке нагрузке в одном большом наборе ЦП, чем между двумя маленькими наборами ЦП, каждый из которых равен половине размера большего набора (точное отношение между количеством балансируемых ЦП и затратами на балансировку зависит от деталей реализации процесса планировщика ядра, который изменяется со временем, улучшаясь по мере реализации в ядре эффективных алгоритмов планирования).

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

По умолчанию, балансировка нагрузки выполняется на всех ЦП, за исключением отмеченных как изолированные при запуске ядра с аргументом «isolcpus=» (смотрите Степень ослабления домена планировщиком далее для изменения этого значения по умолчанию).

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

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

Когда индивидуальный флаг sched_load_balance установлен (по умолчанию), запрашивается балансировка нагрузки на всех разрешённых ЦП в этом процессорном наборе, при балансировке нагрузки может выполняться перемещение процесса (если он не привязан с помощью sched_setaffinity(2)) с любого ЦП в этом процессорном наборе на другой ЦП.

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

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

Поэтому в двух приведённых выше ситуациях флаг sched_load_balance должен быть сброшен у верхнего процессорного набора, и его нужно устанавливать только на отдельных дочерних процессорных наборах.

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

Конечно, процессы, прикреплённые к определённому ЦП, могут оставаться в процессорном наборе с выключенным sched_load_balance, поскольку такие процессы никуда не переместятся в любом случае.

Степень ослабления домена планировщиком

Планировщик ядра безотлагательно (immediate) выполняет балансировку нагрузки как только ЦП становится свободным или ещё одна задача становится выполняемой. Такая балансировка нагрузки работает чтобы гарантировать, что все возможные ЦП заняты полезной работой по выполнению задач. Также ядро выполняет периодическую балансировку нагрузки по программным часам, описанным в time(7). Значение sched_relax_domain_level применяется только к безотлагательной балансировке нагрузки. Независимо от значения sched_relax_domain_level периодическая балансировка нагрузки пытается работать на всех ЦП (если она не выключена в sched_load_balance). В любом случае, задачи будут запланированы к выполнению только на разрешённых ЦП в их процессорных наборах, которые настраиваются с помощью системных вызовов sched_setaffinity(2).

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

Точные значения маленьких целых значений sched_relax_domain_level будет зависеть от внутренней реализации кода планировщика ядра и неоднородности архитектуры аппаратных средств. Оба из них постоянно развиваются и различаются в разных версиях ядра и архитектурах системы.

На момент написания когда это свойство появилось в Linux 2.6.26, на определённых популярных архитектурах положительные значения sched_relax_domain_level были такими:

(1)

Выполнять безотлагательную балансировку нагрузки на одноуровневых потоках Hyper-Thread одного ядра.

(2)

Выполнять безотлагательную балансировку нагрузки на других ядрах того же пакета.

(3)

Выполнять безотлагательную балансировку нагрузки на других ЦП в том же узле или лезвии.

(4)

Выполнять безотлагательную балансировку нагрузки на нескольких (зависит от реализации) узлах (в системах с NUMA).

(5)

Выполнять безотлагательную балансировку нагрузки на всех ЦП системы (в системах с NUMA).

Значение sched_relax_domain_level равное нулю (0) всегда означает отключение безотлагательной балансировки нагрузки, то есть балансировка нагрузки выполняется только периодически, а не сразу после того, как ЦП становится доступным или другая задача становится выполняемой.

Значение sched_relax_domain_level равное минус одному (-1) всегда означает использование системного значения по умолчанию. Системное значение по умолчанию может различаться на разных архитектурах и версиях ядра. Его можно изменить через аргумент команды загрузки ядра «relax_domain_level=».

При наличии нескольких перекрывающихся процессорных наборов, которые имеют конфликтующие значения sched_relax_domain_level, во всех перекрывающихся процессорных наборах на всех ЦП применяется самое большое значение. В таких случаях значение минус один (-1) считается самым маленьким, заменяется любым значением, а значение ноль (0) является следующим самым маленьким значением.

В виде маски

Формат в виде маски используется для представления ЦП и узлов памяти в виде маски битов в файле /proc/<pid>/status.

Данный формат отображает каждое 32-битное слово в шестнадцатеричной форме (используя символы ASCII «0»-«9» и «a»-«f»); если нужно, слова дополняются ведущими нулями. Для масок длиннее слова между словами используется разделитель запятая. Слова отображаются в порядке от старшего к младшему, то есть первым стоит самый значимый бит. Шестнадцатеричные цифры в слове также расположены в порядке от старшего к младшему.

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

Примеры формата в виде маски:

00000001                        # установлен только бит 0
40000000,00000000,00000000      # установлен только бит 94
00000001,00000000,00000000      # установлен только бит 64
000000ff,00000000               # установлены биты 32-39
00000000,000e3862               # установлены 1,5,6,11-13,17-19

Маска с установленными битами 0, 1, 2, 4, 8, 16, 32 и 64 выглядит так:

00000001,00000001,00010117

Первая «1» для бита 64, вторая — для бита 32, третья — для 16, четвёртая — для 8, пятая — для 4 и «7» — для битов 2, 1 и 0.

В виде списка

Формат в виде списка — это список десятичных ASCII значений cpus и mems через запятую для перечисления номеров (и диапазонов) всех ЦП или узлов памяти.

Примеры формата в виде списка:

0-4,9           # установлены биты 0, 1, 2, 3, 4 и 9
0-2,7,12-14     # установлены биты 0, 1, 2, 7, 12, 13 и 14

Включение memory_pressure

По умолчанию, индивидуальный файл cpuset.memory_pressure всегда содержит ноль (0). Если это свойство не включить записью «1» в псевдо-файл /dev/cpuset/cpuset.memory_pressure_enabled, то ядро не вычисляет индивидуальное значение memory_pressure.

Использование команды echo

При использовании команды echo в оболочке командной строки для изменения значений файлов процессорного набора остерегайтесь встроенной в некоторые оболочки команды echo; она не отображает сообщение об ошибке системного вызова write(2). Например, если команда:

echo 19 > cpuset.mems

завершится с ошибкой из-за того, что узел памяти 19 не разрешён (возможно, текущая система не имеет узла памяти 19), то команда echo может не выдать ошибки. Для изменения настроек файла процессорного набора лучше использовать внешнюю команду /bin/echo , так как она выводит ошибки write(2), например:

/bin/echo 19 > cpuset.mems
/bin/echo: write error: Invalid argument

Размещение в памяти

Не каждое выделение системной памяти ограничивается процессорным набором по следующим причинам:

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

Некоторые критичные для ядра запросы на выделение внутренней памяти, помеченные GFP_ATOMIC, должны быть выполнены немедленно. Ядро может отбросить какой-нибудь запрос или сломается, если одно из таких выделений завершится с ошибкой. Если такой запрос не может быть выполнен в текущем процессорном наборе процесса, то мы ослабляем требования процессорного набора, и ищем память где сможем найти. Лучше нарушить указания процессорного набора, чем испортить ядро.

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

Переименование процессорных наборов

Для переименования процессорных наборов можно использовать системный вызов rename(2). Поддерживается только простое переименование; то есть разрешено изменение имени каталога процессорного набора — переместить каталог в другой каталог нельзя.

Создание и прикрепление к процессорному набору.

Для создания нового процессорного набора и прикрепления текущей оболочки команд к нему выполняются следующие шаги:

1)

mkdir /dev/cpuset (если уже не сделано)

2)

mount -t cpuset none /dev/cpuset (если уже не сделано)

3)

Создание нового процессорного набора с помощью mkdir(1).

4)

Назначение ЦП и узлов памяти новому процессорному набору.

5)

Прикрепление оболочки к новому процессорному набору.

Например, следующая последовательность команд создаёт новый процессорный набор с именем «Charlie», содержащий только ЦП 2 и 3, и узел памяти 1, а затем прикрепляет к этому процессорному набору текущую оболочку.

$ mkdir /dev/cpuset
$ mount -t cpuset cpuset /dev/cpuset
$ cd /dev/cpuset
$ mkdir Charlie
$ cd Charlie
$ /bin/echo 2-3 > cpuset.cpus
$ /bin/echo 1 > cpuset.mems
$ /bin/echo $$ > tasks
# Текущая оболочка теперь работает в процессорном наборе Charlie
# Следующая строка должна вывести /Charlie
$ cat /proc/self/cpuset

Перенос задания в другие узлы памяти.

Чтобы перенести задание (набор процессов, присоединённых к процессорному набору) на другие ЦП и узлы памяти в системе, включая перемещение страниц памяти, выделенных под это задание, выполните следующие шаги:

1)

Предположим, мы хотим перенести задание из процессорного набора alpha (ЦП 4-–7 узлы памяти 2–3) в новый процессорный набор beta (ЦП 16-–19 и узлы памяти 8–9).

2)

Сначала создадим новый процессорный набор beta.

3)

Затем включим ЦП 16–19 и узлы памяти 8–9 в beta.

4)

Затем включим флаг memory_migration в beta.

5)

Затем переместим каждый процесс из alpha в beta.

Всё это выполняет следующая последовательность команд:

$ cd /dev/cpuset
$ mkdir beta
$ cd beta
$ /bin/echo 16-19 > cpuset.cpus
$ /bin/echo 8-9 > cpuset.mems
$ /bin/echo 1 > cpuset.memory_migrate
$ while read i; do /bin/echo $i; done < ../alpha/tasks > tasks

Команды выше должны переместить все процессы из alpha в beta, и всю память этих процессов с узлов памяти 2–3 на узлы памяти 8–9, соответственно.

Заметим, что последний шаг не сделан как:

$ cp ../alpha/tasks tasks

Цикл while, а не гораздо более простая команда cp(1), необходим, так как только один PID процесса за раз записывается в файл tasks.

Того же (запись одного PID за раз) как в цикле while можно достичь более эффективно несколькими командами и с синтаксисом, который доступен в любой оболочке, но выглядит непонятно: используя параметр -u (не буферизировать) в sed(1):

$ sed -un p < ../alpha/tasks > tasks