Почему планировщик Linux помещает два потока на одно физическое ядро на процессорах с HyperThreading?

Я читал в нескольких местах, что планировщик Linux по умолчанию с поддержкой hyperthreading на многоядерных машинах, что означает, что если у вас есть машина с 2 реальными ядрами (4 HT), она не будет планировать два занятых потока на логические ядра таким образом, чтобы они оба работали на одних и тех же физических ядрах (что во многих случаях приводило бы к 2-х издержкам).

Но когда я запускаю stress -c 2 (порождает два потока для запуска на 100% процессоре) на моем Intel i5-2520M, он часто планирует (и сохраняет) два потока на HT ядра 1 и 2, которые сопоставляются с одним и тем же физическим ядром. Даже если система не работает в противном случае.

Это также происходит с реальными программами (я использую stress здесь, потому что это позволяет легко воспроизвести), и когда это происходит, моя программа, по понятным причинам, занимает в два раза больше времени для запуска. Настройка привязки вручную с помощью taskset исправляет, что для моей программы, но я ожидал бы, что планировщик, поддерживающий HT, сделает это правильно сам по себе.

Вы можете найти HT- > физическое ядро с помощью egrep "processor|physical id|core id" /proc/cpuinfo | sed 's/^processor/\nprocessor/g'.

Итак, мой вопрос: Почему планировщик помещает мои потоки в одно и то же физическое ядро здесь?

Примечания:

Этот вопрос очень похож на этот другой вопрос, ответы на которые говорят, что Linux имеет довольно сложный планировщик потоков, который известен HT. Как описано выше, я не могу наблюдать этот факт (проверьте себя stress -c) и хотел бы знать, почему.
Я знаю, что я могу настроить совместимость процессоров вручную для моих программ, например. с помощью инструмента taskset или с помощью функции sched_setaffinity. Это не то, что я ищу, я бы ожидал, что планировщик сам знает, что отображение двух занятых потоков в физическое ядро и оставление одного физического ядра полностью пустым - не очень хорошая идея.
Я знаю, что есть некоторые ситуации, в которых вы предпочли бы, чтобы потоки были запланированы на одно и то же физическое ядро и оставили другое ядро свободным, но кажется бессмысленно, что планировщик будет делать примерно 1/4 из этих случаев. Мне кажется, что ядра HT, которые он выбирает, являются полностью случайными, или, возможно, те HT-ядра, которые имели наименьшую активность во время планирования, но это не было бы очень гиперпотоком, учитывая, насколько ясно программы с характеристиками stress извлекайте выгоду из работы на отдельных физических ядрах.

Ответ 1

Я думаю, что настало время обобщить некоторые знания из комментариев.

Linux-планировщик знает об HyperThreading - информация о нем должна быть прочитана из таблиц ACPI SRAT/SLIT, которые предоставляются BIOS/UEFI, - чем Linux строит домены планировщика.

Домены имеют иерархию - то есть на серверах с двумя процессорами вы получите три уровня доменов: all-cpus, per-cpu-package и per-cpu-core. Вы можете проверить его с помощью /proc/schedstat:

$ awk '/^domain/ { print $1, $2; } /^cpu/ { print $1; }' /proc/schedstat
cpu0
domain0 0000,00001001     <-- all cpus from core 0
domain1 0000,00555555     <-- all cpus from package 0
domain2 0000,00ffffff     <-- all cpus in the system

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

При этом он проверяет, исчерпал ли текущий домен его промежуток ребалансировки. Если это так, он запускает load_balance() в этом домене. Затем он проверяет родительский sched_domain (если он существует) и родительский элемент родителя и так д.

Изначально load_balance() находит самую занятую группу в текущем домене расписания. Если он преуспеет, он ищет самый загруженный runqueue всех запусков процессоров в эта группа. Если ему удастся найти такой runqueue, он блокирует и наши начальные CPU runqueue и вновь найденный самый загруженный и запускает из него задачи к нашему бегу. Точное количество задач составляет дисбаланс ранее вычисленный во время итерации по этим группам домена планирования.

От: https://www.kernel.org/doc/Documentation/scheduler/sched-domains.txt

Вы можете отслеживать действия балансировки нагрузки путем сравнения чисел в /proc/schedstat. Я написал script для этого: schedstat.py

Счетчик alb_pushed показывает, что балансировка нагрузки была успешно перенесена:

Sun Apr 12 14:15:52 2015              cpu0    cpu1    ...    cpu6    cpu7    cpu8    cpu9    cpu10   ...
.domain1.alb_count                                    ...      1       1                       1  
.domain1.alb_pushed                                   ...      1       1                       1  
.domain2.alb_count                              1     ...                                         
.domain2.alb_pushed                             1     ...

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

Я вижу две возможности для этого поведения:

У вас есть агрессивная политика энергосбережения, которая пытается сохранить одно ядро для снижения энергопотребления процессора.
Вы действительно столкнулись с ошибкой с подсистемой планирования, чем вы должны пойти в LKML и тщательно поделиться своими выводами (включая mpstat и schedstat данные)

Ответ 2

Я не могу воспроизвести это на 3.13.0-48 с моим процессором Intel (R) Xeon (R) E5-1650 0 @3.20GHz.

У меня есть 6 ядер с гиперпотоком, где логическое ядро N отображает физическое ядро N mod 6.

Здесь типичный вывод top с stress -c 4 в двух столбцах, так что каждая строка является одним физическим ядром (я оставил несколько ядер, потому что моя система не простаивает):

%Cpu0  :100.0 us,   %Cpu6  :  0.0 us, 
%Cpu1  :100.0 us,   %Cpu7  :  0.0 us, 
%Cpu2  :  5.9 us,   %Cpu8  :  2.0 us, 
%Cpu3  :100.0 us,   %Cpu9  :  5.7 us, 
%Cpu4  :  3.9 us,   %Cpu10 :  3.8 us, 
%Cpu5  :  0.0 us,   %Cpu11 :100.0 us,

Вот он после убийства и перезапуска stress:

%Cpu0  :100.0 us,   %Cpu6  :  2.6 us, 
%Cpu1  :100.0 us,   %Cpu7  :  0.0 us, 
%Cpu2  :  0.0 us,   %Cpu8  :  0.0 us, 
%Cpu3  :  2.6 us,   %Cpu9  :  0.0 us, 
%Cpu4  :  0.0 us,   %Cpu10 :100.0 us, 
%Cpu5  :  2.6 us,   %Cpu11 :100.0 us,

Я делал это несколько раз и не видел ни одного экземпляра, где 4 потока по 12 логическим ядрам планировались бы на одном физическом ядре.

С -c 6 Я имею тенденцию получать такие результаты, когда Linux, по-видимому, помогает в планировании других процессов на своих физических ядрах. Тем не менее, они распределены лучше, чем вероятность:

%Cpu0  : 18.2 us,   %Cpu6  :  4.5 us, 
%Cpu1  :  0.0 us,   %Cpu7  :100.0 us, 
%Cpu2  :100.0 us,   %Cpu8  :100.0 us, 
%Cpu3  :100.0 us,   %Cpu9  :  0.0 us, 
%Cpu4  :100.0 us,   %Cpu10 :  0.0 us, 
%Cpu5  :100.0 us,   %Cpu11 :  0.0 us,

Ответ 3

Процитировав свой опыт с двумя дополнительными процессорами, которые, казалось, работали правильно, i7-2600 и Xeon E5-1620; Это может быть длинный, но как насчет обновления микрокода процессора? Он может включать в себя что-то, чтобы устранить проблему, если это внутреннее поведение процессора.

Загрузка микрокода Intel CPU: http://intel.ly/1aku6ak

Также см. здесь: https://wiki.archlinux.org/index.php/Microcode