Скрипт для отключения гиперпоточности при запуске машины ...
Чтобы отключить гиперпоточность, я включаю скрипт на машине /etc/rc.local. Он не совсем чистый, но простой в установке, независимый от архитектуры процессора и должен работать на любом современном дистрибутиве Linux.
nano /etc/rc.local
# place this near the end before the "exit 0"
for CPU in /sys/devices/system/cpu/cpu[0-9]*; do
CPUID=$(basename $CPU)
echo "CPU: $CPUID";
if test -e $CPU/online; then
echo "1" > $CPU/online;
fi;
COREID="$(cat $CPU/topology/core_id)";
eval "COREENABLE=\"\${core${COREID}enable}\"";
if ${COREENABLE:-true}; then
echo "${CPU} core=${CORE} -> enable"
eval "core${COREID}enable='false'";
else
echo "$CPU core=${CORE} -> disable";
echo "0" > "$CPU/online";
fi;
done;
Как это работает?
Информация о ядре Linux и элементы управления доступны в виде файлов в каталоге / sys в современных дистрибутивах Linux. Например:
/ sys / devices / system / cpu / cpu3
содержит информацию о ядре и элементы управления для логического процессора 3.
cat / sys / devices / system / cpu / cpu3 / topology / core_id
покажет номер ядра, которому принадлежит этот логический процессор.
echo "0"> / sys / devices / system / cpu / cpu3 / online
позволяет отключить логический процессор 3.
Почему это работает?
Я не знаю точно, почему ... но система стала более отзывчивой с отключенной гиперпоточностью (на моем ноутбуке i5 и массивных серверах Xeon с более чем 60 ядрами). Я предполагаю, что это связано с кэшем для каждого процессора, выделением памяти для каждого процессора, выделением планировщика процессора и сложными итерациями приоритетов процесса. Я думаю, что преимущества гиперпоточности перевешивают сложность создания планировщиков ЦП, которые знают, как их использовать.
Для меня проблема с гиперпоточностью такова: если я запущу столько потоков с интенсивным использованием процессора, сколько у меня логических ядер, у меня будут быстрые переключатели контекста для задач с интенсивным использованием процессора, но дорогие для фоновых задач, поскольку гиперпоточность полностью используется интенсивные задачи процессора. С другой стороны, если я запускаю столько потоков с интенсивным использованием процессора, сколько у меня физических ядер, у меня не будет переключений контекста на эти задачи и быстрых переключений контекста для фоновых задач. Вроде бы хорошо, но фоновые задачи найдут свободные логические процессоры и будут работать почти сразу. Как будто они в реальном времени (неплохо -20).
В первом сценарии гиперпоточность - это пустяки, фоновые задачи будут использовать дорогие переключатели контекста, потому что я увеличил гиперпоточность при обычной обработке. Второе недопустимо, поскольку до 50% мощности моего процессора отдается приоритет фоновым задачам.
«Интенсивная загрузка процессора», о которой я говорю, - это интеллектуальный анализ данных и серверы авторизации (моя работа). Блендер рендеринг в дешевых компьютерах и кластерах (для эскиза моего будущего дома).
Кроме того, это догадки.
У меня такое впечатление, что лучше, но может и нет.
sysbench --num-threads=1 --test=cpu runс разными num-потоками и включенным и выключенным HT говорит о том, что отключение HT снижает производительность, когда есть много потоков, и даже если есть только один поток, нет смысла отключать HT. Поэтому я предлагаю оставить все как есть: это оптимально.