Команда Taskset-c?
Вы могли сказать мне, как использовать команду taskset на Linux?
Существует спецификация моего процессора:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 21
Model: 16
Model name: AMD A8-4500M APU with Radeon(tm) HD Graphics
Stepping: 1
CPU MHz: 1900.000
CPU max MHz: 1900,0000
CPU min MHz: 1400,0000
BogoMIPS: 3792.85
Virtualization: AMD-V
L1d cache: 16K
L1i cache: 64K
L2 cache: 2048K
NUMA node0 CPU(s): 0-3
Когда я поместил taskset -c 0-3 перед командой для выполнения openflow контроллер, у меня есть худший результат на тесте cbench чем тогда, когда я использую команду taskset -c 0 перед той же командой (для рабочего контроллера).
Как это возможно? Я ожидал, что у меня есть лучший результат, когда я использую 4 потока чем тогда, когда я использую только один поток?
1 ответ
Это - сложный предмет, в зависимости от многих переменных, включая который планировщик, драйвер частоты ЦП и регулятор, задержки состояния ожидания, процессор...
И в то время как большая работа вошла в то, чтобы заставлять различные драйверы частотного масштабирования ЦП правильно ответить на рабочие нагрузки, существуют просто сценарии, где результаты удивительно плохи. Это может произойти с обоими многопоточными или единственными потоковыми приложениями. Например, ffmpeg и нечетный способ, которым это вращается через центральные процессоры, особенно сложное приложение для драйверов частотного масштабирования ЦП. На моем компьютере с 8 центральными процессорами я получаю лучшие результаты с phoronix ffmpeg тест, если я ограничиваю его 4 центральными процессорами вместо 8.
Позволяют нам работать через простой единственный потоковый пример. У меня есть простая программа записи ЦП, которая сделает немного блока работы, и при выполнении высокоуровневый сценарий затянет, другой обрабатывает, действительно делают еще небольшой блок работы, и так далее для некоторого количества циклов. Если я выполняю это задание, не ограничивая количество выделенных центральных процессоров, то требуется 104 секунды, но если я ограничиваю его одним ЦП, требуется 54 секунды. Почему такое встречное интуитивное и решительное различие? Поскольку во время блока работы, драйвер частотного масштабирования ЦП / комбинация регулятора действительно понимает, что ЦП полностью загружается и начал поднимать частоту ЦП. Однако между тем концы блока работы и следующее запускаются. Теперь планировщик еще на самом деле не знает, что первый блок работы закончился, таким образом, это думает, что ЦП полностью загружается и поэтому решает присвоить другой ЦП новому блоку работы. Первый ЦП входит в глубокое состояние ожидания и больше не влияет на желаемую рабочую частоту ЦП. Между тем новый ЦП только начинает увеличивать свою рабочую частоту в ответ на загрузку. Этот цикл продолжается и на том, так что в итоге рабочая частота ЦП никогда не становится очень высокой.
Теперь, в случае, где только один ЦП выделяется заданию, никогда нет разрыва загрузки на том ЦП, и в конечном счете это достигает максимальной рабочей частоты, и блоки работы завершаются намного быстрее.
данные В качестве примера (всегда то же задание, никакие IO не ожидают включенные):
One CPU allocated:
(driver = intel_pstate; governor = powersave):
real 0m54.830s
user 0m48.112s
sys 0m0.272s
No restriction on CPU allocation (i.e. all 8 are available):
(driver = intel_pstate; governor = powersave):
real 1m54.938s
user 1m47.948s
sys 0m0.336s
No restriction on CPU allocation (i.e. all 8 are available):
(driver = intel_pstate; governor = performance):
real 0m52.851s
user 0m48.044s
sys 0m0.212s
Итак, почему не только используют регулятор производительности все время? Поскольку, и в целом, который потратил бы впустую много энергии напрасно. Это - просто эти специальные нечетные варианты использования, где могло бы быть лучше просто использовать регулятор производительности.