Контекст переключается гораздо медленнее в новых ядрах Linux

Мы хотим обновить ОС на наших серверах от Ubuntu 10.04 LTS до Ubuntu 12.04 LTS. К сожалению, кажется, что латентность для запуска потока, который стал runnable, значительно увеличился с ядра 2.6 до ядра 3.2. На самом деле количество времени ожидания, которое мы получаем, трудно поверить.

Позвольте мне более конкретно про тест. У нас есть программа, которая запускает два потока. Первый поток получает текущее время (в тиках с использованием RDTSC), а затем сигнализирует переменную состояния один раз в секунду. Второй поток ожидает переменную условия и просыпается, когда она сигнализируется. Затем он получает текущее время (в тиках с использованием RDTSC). Разность между временем во втором потоке и временем в первом потоке вычисляется и отображается на консоли. После этого второй поток снова ждет переменную условия. Он будет сигнализирован снова первой нитью примерно через секунду.

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

В ядре 2.6.32 эта латентность находится где-то порядка 2.8-3.5 мкс, что разумно. В ядре 3.2.0 эта латентность увеличилась примерно до 40-100 человек. Я исключил любые различия в оборудовании между двумя хостами. Они работают на идентичном оборудовании (двухсетевые процессоры X5687 {Westmere-EP}, работающие на частоте 3,6 ГГц, с отключением гиперпотока, скоростью и всеми состояниями C). Приложение-тест изменяет близость потоков для их запуска на независимых физических ядрах одного и того же сокета (т.е. Первый поток запускается на Core 0, а второй поток запускается на Core 1), поэтому нет отскока потоков на ядра или переключение/связь между сокетами.

Единственное различие между этими двумя хостами заключается в том, что на нем запущен Ubuntu 10.04 LTS с ядром 2.6.32-28 (переключатель быстрого контекстного контекста), а другой работает с последней версией Ubuntu 12.04 LTS с ядром 3.2.0-23 ( переключатель медленного контекстного контекста). Все настройки и оборудование BIOS идентичны.

Были ли какие-либо изменения в ядре, которые могли бы объяснить это смехотворное замедление в том, сколько времени требуется для запуска потока, который планируется запустить?

Update: Если вы хотите запустить тест на своем хосте и сборке linux, я отправил код в pastebin для вашего прочтения. Скомпилировать с помощью:

g++ -O3 -o test_latency test_latency.cpp -lpthread

Запустите с (если у вас есть хотя бы двухъядерный ящик):

./test_latency 0 1 # Thread 1 on Core 0 and Thread 2 on Core 1

Обновление 2: После многократного поиска параметров ядра, сообщений об изменениях ядра и личных исследований я выяснил, в чем проблема, и разместил решение в качестве ответа на этот вопрос.

ОТВЕТЫ

Ответ 1

Решение проблемы проблемы с плохим потоком в последних ядрах связано с переключением на драйвер intel_idle cpuidle от acpi_idle, который используется в старых ядрах. К сожалению, драйвер intel_idle игнорирует конфигурацию пользовательских BIOS для C-состояний и танцев на собственную мелодию. Другими словами, даже если вы полностью отключите все состояния C в BIOS вашего компьютера (или сервера), этот драйвер все равно заставит их работать в периоды кратковременной бездействия, которые почти всегда происходят, если только весь основной потребляющий синтетический бенчмарк (например, стресс ) бежит. Вы можете отслеживать переходы состояния C вместе с другой полезной информацией, касающейся частот процессора, используя замечательный инструмент Google i7z на большинстве совместимых аппаратных средств.

Чтобы узнать, какой драйвер cpuidle в данный момент активен в вашей настройке, просто напишите файл current_driver в разделе cpuidle /sys/devices/system/cpu следующим образом:

cat /sys/devices/system/cpu/cpuidle/current_driver

Если вы хотите, чтобы ваша современная ОС Linux имела наименьшую задержку переключения контекста, добавьте следующие параметры загрузки ядра, чтобы отключить все эти функции энергосбережения:

В Ubuntu 12.04 вы можете сделать это, добавив их в запись GRUB_CMDLINE_LINUX_DEFAULT в /etc/default/grub, а затем запустив update-grub. Добавляемые параметры загрузки:

intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll

Вот подробные сведения о трех вариантах загрузки:

Установка intel_idle.max_cstate в ноль приведет к возврату вашего драйвера cpuidle к acpi_idle (по крайней мере, в документации по опции) или полностью отключить его. На моем ящике он полностью отключен (т.е. Отображение файла current_driver в /sys/devices/system/cpu/cpuidle приводит к выходу none). В этом случае второй вариант загрузки processor.max_cstate=0 не нужен. Однако в документации указано, что установка max_cstate в ноль для драйвера intel_idle должна вернуть ОС к драйверу acpi_idle. Поэтому на всякий случай я поставил второй вариант загрузки.

Параметр processor.max_cstate устанавливает максимальное значение состояния C для драйвера acpi_idle равным нулю, что также позволяет отключить его. У меня нет системы, на которой я могу проверить это, потому что intel_idle.max_cstate=0 полностью выбивает драйвер cpuidle на все доступные мне аппаратные средства. Однако если ваша установка вернет вас с intel_idle до acpi_idle только с первой загрузкой, сообщите мне, если второй вариант processor.max_cstate сделал то, что было задокументировано, чтобы делать в комментариях, чтобы я мог обновить этот ответ.

Наконец, последний из трех параметров idle=poll является реальным силовым болотом. Он отключит C1/C1E, который удалит последний оставшийся бит латентности за счет гораздо большего энергопотребления, поэтому используйте его только тогда, когда это действительно необходимо. Для большинства это будет излишним, так как латентность C1 * не так велика. Используя мое тестовое приложение, запущенное на аппаратном обеспечении, которое я описал в исходном вопросе, латентность прошла с 9 до 3 мы. Это, безусловно, значительное сокращение для чувствительных к высокой чувствительности приложений (например, финансовая торговля, высокоточная телеметрия/отслеживание, получение высокочастотных данных и т.д.), Но, возможно, не стоит того, чтобы понести электрическую энергию для подавляющего большинства настольных приложений. Единственный способ узнать наверняка - это улучшить ваше приложение в производительности по сравнению с фактическим увеличением потребления энергии/тепла вашего оборудования и взвесить компромиссы.

Update:

После дополнительного тестирования с различными параметрами idle=* я обнаружил, что настройка idle на mwait, если поддерживается вашим оборудованием, является гораздо лучшей идеей. Похоже, что использование инструкций MWAIT/MONITOR позволяет ЦП войти в C1E без какой-либо заметной задержки, добавляемой к времени пробуждения нити. С помощью idle=mwait вы получите более низкие температуры процессора (по сравнению с idle=poll), уменьшите потребление энергии и сохраните отличные низкие задержки цикла простоя опроса. Поэтому мой обновленный рекомендуемый набор параметров загрузки для низкой задержки потока нити процессора на основе этих результатов:

intel_idle.max_cstate=0 processor.max_cstate=0 idle=mwait

Использование idle=mwait вместо idle=poll также может помочь в инициировании Turbo Boost (помогая CPU оставаться ниже его TDP [Thermal Design Power]) и гиперпотоков (для которых MWAIT - идеальный механизм для не потребляя всего физического ядра, в то же время избегая более высоких состояний С). Однако это еще предстоит доказать при тестировании, которое я буду продолжать делать.

Обновление 2:

Параметр mwait idle был удален из более новых ядер 3.x (благодаря пользователю ck_ для обновления). Это оставляет нам два варианта:

idle=halt - должен работать так же, как и mwait, но проверьте, чтобы это было в случае с вашим оборудованием. Инструкция HLT почти эквивалентна mwait с подсказкой состояния 0. Проблема заключается в том, что требуется прерывание, чтобы выйти из состояния HLT, в то время как запись (или прерывание) памяти может быть использована для получения из состояния MWAIT. В зависимости от того, что использует ядро ​​Linux в своем холостом цикле, это может сделать MWAIT потенциально более эффективным. Итак, как я сказал тест/профиль и посмотреть, соответствует ли он вашим ожиданиям латентности...

и

idle=poll - Самая высокая производительность, за счет мощности и тепла.

Ответ 2

Возможно, что стало медленнее, это futex, строительный блок для переменных условия. Это прольет свет:

strace -r ./test_latency 0 1 &> test_latency_strace & sleep 8 && killall test_latency

затем

for i in futex nanosleep rt_sig;do echo $i;grep $i test_latency_strace | sort -rn;done

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

В ядре 2.6.32

$ for i in futex nanosleep rt_sig;do echo $i;grep $i test_latency_strace | sort -rn;done
futex
 1.000140 futex(0x601ac4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601ac0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000129 futex(0x601ac4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601ac0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000124 futex(0x601ac4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601ac0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000119 futex(0x601ac4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601ac0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000106 futex(0x601ac4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601ac0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000103 futex(0x601ac4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601ac0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000102 futex(0x601ac4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601ac0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 0.000125 futex(0x7f98ce4c0b88, FUTEX_WAKE_PRIVATE, 2147483647) = 0
 0.000042 futex(0x601b00, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000038 futex(0x601b00, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000037 futex(0x601b00, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000030 futex(0x601b00, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000029 futex(0x601b00, FUTEX_WAKE_PRIVATE, 1) = 0
 0.000028 futex(0x601b00, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000027 futex(0x601b00, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000018 futex(0x7fff82f0ec3c, FUTEX_WAKE_PRIVATE, 1) = 0
nanosleep
 0.000027 nanosleep({1, 0}, {1, 0}) = 0
 0.000019 nanosleep({1, 0}, {1, 0}) = 0
 0.000019 nanosleep({1, 0}, {1, 0}) = 0
 0.000018 nanosleep({1, 0}, {1, 0}) = 0
 0.000018 nanosleep({1, 0}, {1, 0}) = 0
 0.000018 nanosleep({1, 0}, {1, 0}) = 0
 0.000018 nanosleep({1, 0}, 0x7fff82f0eb40) = ? ERESTART_RESTARTBLOCK (To be restarted)
 0.000017 nanosleep({1, 0}, {1, 0}) = 0
rt_sig
 0.000045 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000040 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000038 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000035 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000034 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000033 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000032 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000032 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000031 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000031 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000028 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000028 rt_sigaction(SIGRT_1, {0x37f8c052b0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x37f8c0e4c0}, NULL, 8) = 0
 0.000027 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000027 rt_sigaction(SIGRTMIN, {0x37f8c05370, [], SA_RESTORER|SA_SIGINFO, 0x37f8c0e4c0}, NULL, 8) = 0
 0.000027 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000025 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000025 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000023 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000023 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000022 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
 0.000022 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000021 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000021 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000021 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000021 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000021 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000019 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0

В ядре 3.1.9

$ for i in futex nanosleep rt_sig;do echo $i;grep $i test_latency_strace | sort -rn;done
futex
 1.000129 futex(0x601764, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601760, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000126 futex(0x601764, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601760, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000122 futex(0x601764, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601760, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000115 futex(0x601764, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601760, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000114 futex(0x601764, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601760, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000112 futex(0x601764, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601760, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 1.000109 futex(0x601764, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x601760, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
 0.000139 futex(0x3f8b8f2fb0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
 0.000043 futex(0x601720, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000041 futex(0x601720, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000037 futex(0x601720, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000036 futex(0x601720, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000034 futex(0x601720, FUTEX_WAKE_PRIVATE, 1) = 1
 0.000034 futex(0x601720, FUTEX_WAKE_PRIVATE, 1) = 1
nanosleep
 0.000025 nanosleep({1, 0}, 0x7fff70091d00) = 0
 0.000022 nanosleep({1, 0}, {0, 3925413}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
 0.000021 nanosleep({1, 0}, 0x7fff70091d00) = 0
 0.000017 nanosleep({1, 0}, 0x7fff70091d00) = 0
 0.000017 nanosleep({1, 0}, 0x7fff70091d00) = 0
 0.000017 nanosleep({1, 0}, 0x7fff70091d00) = 0
 0.000017 nanosleep({1, 0}, 0x7fff70091d00) = 0
 0.000017 nanosleep({1, 0}, 0x7fff70091d00) = 0
rt_sig
 0.000045 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000044 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000043 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000040 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000038 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000037 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000036 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000036 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000035 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000035 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000035 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000035 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000034 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000031 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000027 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000027 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000027 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000027 rt_sigaction(SIGRT_1, {0x3f892067b0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x3f8920f500}, NULL, 8) = 0
 0.000026 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000026 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000025 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000024 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000023 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
 0.000023 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 0.000022 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 0.000021 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
 0.000019 rt_sigaction(SIGRTMIN, {0x3f89206720, [], SA_RESTORER|SA_SIGINFO, 0x3f8920f500}, NULL, 8) = 0

Я нашел этот 5-летний отчет об ошибках, содержащий тест производительности "пинг-понг", который сравнивает

  • однопоточный мьютекс libpthread
  • переменная условия libpthread
  • простые старые сигналы Unix

Мне пришлось добавить

#include <stdint.h>

чтобы скомпилировать, что я сделал с этой командой

g++ -O3 -o condvar-perf condvar-perf.cpp -lpthread -lrt

В ядре 2.6.32

$ ./condvar-perf 1000000
NPTL
mutex                 elapsed:    29085 us; per iteration:   29 ns / 9.4e-05 context switches.
c.v. ping-pong test   elapsed:  4771993 us; per iteration: 4771 ns / 4.03 context switches.
signal ping-pong test elapsed:  8685423 us; per iteration: 8685 ns / 4.05 context switches.

В ядре 3.1.9

$ ./condvar-perf 1000000
NPTL
mutex                 elapsed:    26811 us; per iteration:   26 ns / 8e-06 context switches.
c.v. ping-pong test   elapsed: 10930794 us; per iteration: 10930 ns / 4.01 context switches.
signal ping-pong test elapsed: 10949670 us; per iteration: 10949 ns / 4.01 context switches.

Я заключаю, что между ядром 2.6.32 и 3.1.9 контекстный переключатель действительно замедлился, хотя и не так сильно, как вы наблюдаете в ядре 3.2. Я понимаю, что это еще не отвечает на ваш вопрос, я буду продолжать рыть.

Изменить: я обнаружил, что изменение приоритета процесса в реальном времени (оба потока) улучшает производительность на 3.1.9 в соответствии с 2.6.32. Однако установка того же приоритета на 2.6.32 заставляет его замедляться... go figure - я рассмотрю его больше.

Вот мои результаты сейчас:

В ядре 2.6.32

$ ./condvar-perf 1000000
NPTL
mutex                 elapsed:    29629 us; per iteration:   29 ns / 0.000418 context switches.
c.v. ping-pong test   elapsed:  6225637 us; per iteration: 6225 ns / 4.1 context switches.
signal ping-pong test elapsed:  5602248 us; per iteration: 5602 ns / 4.09 context switches.
$ chrt -f 1 ./condvar-perf 1000000
NPTL
mutex                 elapsed:    29049 us; per iteration:   29 ns / 0.000407 context switches.
c.v. ping-pong test   elapsed: 16131360 us; per iteration: 16131 ns / 4.29 context switches.
signal ping-pong test elapsed: 11817819 us; per iteration: 11817 ns / 4.16 context switches.
$

В ядре 3.1.9

$ ./condvar-perf 1000000
NPTL
mutex                 elapsed:    26830 us; per iteration:   26 ns / 5.7e-05 context switches.
c.v. ping-pong test   elapsed: 12812788 us; per iteration: 12812 ns / 4.01 context switches.
signal ping-pong test elapsed: 13126865 us; per iteration: 13126 ns / 4.01 context switches.
$ chrt -f 1 ./condvar-perf 1000000
NPTL
mutex                 elapsed:    27025 us; per iteration:   27 ns / 3.7e-05 context switches.
c.v. ping-pong test   elapsed:  5099885 us; per iteration: 5099 ns / 4 context switches.
signal ping-pong test elapsed:  5508227 us; per iteration: 5508 ns / 4 context switches.
$

Ответ 3

Вы также можете увидеть процессоры, щелкнув вниз в более поздних процессах и ядрах Linux из-за драйвера pstate, который отделен от c-состояний. Таким образом, чтобы отключить это, вы можете указать следующий параметр ядра:

intel_pstate=disable