Процессоры с P и E ядрами появились сравнительно недавно и как с ними уживаться все еще ломают голову разработчики.
Однако на самом деле эта дискриминация на первоклассные и второсортные ядра процессора появилась еще раньше. И пришлось изобретать свои костыли, чтобы важное запускалось на быстрых, а неважное на медленных ядрах.
Речь идет о турбо частоте. Суть в том, что практически у любого процессора базовая частота не имеет никакого значения. В режиме энергосбережения частота может быть сильно ниже базовой, а под полной загрузкой всех ядер частота также немного выше базовой (all core turbo). И конечно же, при условии отсутствия нагрузки на других, одно или несколько ядер могут повышать частоту еще выше до значения turbo.
Однако есть линейки процессоров (в частности это Xeon E5 v4), у которых определенные ядра ни при каких условиях не могут поднять частоту выше all core turbo. Будем называть их "медленными".
Все испытания провожу на домашнем роутере под ОС Debian и Xeon E5-1630v4 (4 ядра, 8 потоков, 3.7 ГГц базовая, 4.0 ГГц турбо)
apt install linux-cpupower
По-умолчанию скорей всего (если специально не менять ничего в BIOS) будут включены все C-states процессора:
watch -n0.5 "cpupower monitor -c"
Вкратце: это уровни энергосбережения. Чем выше уровень, тем в более глубоком сне находится ядро и тем дольше оно из него выходит. Поэтому там где нужна больше скорость работы, а не энергосбережение, то рекомендуется держать ядра не глубже C3. А где нужна самая максимальная отзывчивость - C1, однако в этом режиме уже не будет никаких turbo частот. Поэтому ограничить на сервере до C3 - оптимальное решение, когда и хорошая отзывчивость и ядра могут повышать частоту до turbo. Помимо C-states есть также другие параметры, которыми можно смещать работу процессора либо в сторону скорости, либо в сторону экономии энергии (governor, performance bias... и все эти изменения делаются/не_делаются как в ОС, так и в BIOS - нужно рассматривать конкретный процессор и конкретную мат. плату), но здесь не об этом.
Подчеркну лишь, что в большинстве случаев по-умолчанию баланс смещен именно в сторону экономии энергии. И без ручного вмешательства процессор может не быть таким быстрым как мог бы, хотелось бы...
Проверяем теорию о медленных ядрах. Отключаем у всех ядер C1E и C3:
cpupower -c all idle-set -d2
cpupower -c all idle-set -d3
И дальше поочередно отключаем C6 у каждого из ядер, загоняя принудительно только это ядро в C1
cpupower -c 0 idle-set -d4
Видим, что ядро 0 теперь 99% времени простаивает в C1, т.е. полностью готово к работе. Хотя и работы на нем никакой не выполняется. Но главное, видим что частота его не выше 3.8 ГГц
Включаем обратно cpupower -c 0 idle-set -e4
И отключаем C6 у следующего:
cpupower -c 4 idle-set -d4
Виртуальное ядро 4 также у нас не подымается выше 3.8 ГГц
cpupower -c 1 idle-set -d4
А вот и первое ядро здорового человека, которое может подняться под 4 ГГц. Не совсем т.к. помимо этой программной настройки есть еще аппаратное управление в самом процессоре, на которое никак не повлиять. До самого максимума ядро сможет разогнаться только если на нем еще и нагрузка хоть какая-то будет.
Также мы видим, что следующее ядро 5 тоже подскочило в частоте. Т.е. виртуальные ядра 1 и 5 - это одно физическое ядро и частоты у них связаны.
cpupower -c 5 idle-set -d4
Соответственно разгоняя ядро 5 поднимается частота и у ядра 1
cpupower -c 2 idle-set -d4
cpupower -c 6 idle-set -d4
Выяснили, что ядра 2 и 6 также могут, если захотят.
cpupower -c 3 idle-set -d4
cpupower -c 7 idle-set -d4
А ядра 3/7 как и 0/4 тоже не выше 3.8 ГГц.
Итого расклад по максимальным частотам у нас получился такой:
0 - 3.8
4 - 3.8
1 - 4.0
5 - 4.0
2 - 4.0
6 - 4.0
3 - 3.8
7 - 3.8
Так в чем же проблема?
Обычно процессы запускаются на первом попавшем случайном ядре. Конечно это не доставляет неудобств в большинстве случаев и никто вообще не заморачивается такими мелочами. Особенно если задачи многопоточные и малотребовательные к CPU - типа Nginx например. Однако есть случаи, когда запускаемый процесс точно лишь однопоточный и внутренняя жаба начинает душить от осознания того что этот процесс в 50% случаев (на данном процессоре) запускается на медленных ядрах и выполняется хоть немного, но медленней чем мог бы...
На помощь приходит комманда taskset
Ею мы можем ограничивать какие конкретно ядра будут доступны для запускаемого процесса.
Для примера запакуем в 1 поток полугигабайтный каталог /usr/share на ядре 0:
и потом на ядре 1:
Отличие в 5 сек. Да, разница не такая большая как была бы с современными P и E ядрами, но она есть.
Еще примечательно, что даже поднимая частоту лишь на 1 из ядер все остальные также подтягиваются к 3.8. Хоть они и находятся в C6 режиме энергосбережения. И если просто поднять частоту на всех быстрых ядрах, то итоговая максимальная частота каждого будет заметно не дотягивать до 4.0 ГГц.
Запустим архивирование в 1 поток на одном из быстрых ядер:
Видим, что при условии когда все остальные ядра находятся в покое, частота этого загруженного ядра увеличивается практически до самого верхнего потолка в 4.0 ГГц.
Загрузим все 4 быстрых ядра 4-х поточным архивированием:
Все еще хорошо конечно, однако заметно как максимальная частота каждого отдалилась от отметки 4.0 ГГц.
Ну и загрузим по максимуму все 8 ядер:
Получили all core turbo в 3.8 ГГц.
Раскрасив на графике мониторинга (collectd + rrdtool) ядра 1,5,2,6 красным, а остальные зеленым (не смотрим на подпись под графиком), наглядно видим как зеленые никогда не выходят выше, куда могут красные:
Как это использовать на практике? Каждый решит для себя. На своем хостинге к примеру, я ограничил малозначимые процессы только медленными ядрами. Ни к чему чтобы FTP, DNS и подобные задачи вообще присутствовали на быстрых ядрах. Чтобы на этих быстрых исполнялось лишь то, что действительно важно - MySQL и PHP. В файле службы добавляем все тот же taskset и список медленных ядер (в данном случае процессор E5-1650v4):
Можно конечно сделать обратное ограничение, повесить определенные задачи только на быстрые ядра:
MySQL будет работать замечательно и максимально возможно быстро... но лишь до поры пока нагрузка не большая и в основном однопоточная. Нужно быть осторожным т.к. если к базам будут приходить больше 4 параллельных запросов, то суммарная производительность конечно же наоборот уменьшится, ведь мы по-сути ограничили этот процесс лишь 4мя ядрами.
В целом конечно же подобные процессоры очень неудобны и гораздо лучше когда все ядра равны.
Особенно печально если ваш VPS хостер использует подобные процессоры и вас поселят именно на подобные медленные ядра, которые никогда, ни при каких условиях не смогут приблизиться к турбо-частоте (За которую вы наверняка заплатили, поверив рекламе). И вы врядли сможете подобрать слова, чтоб объяснить/доказать проблему поддержке.
Комментарии (52)
screwer
02.01.2023 19:534 тысячи рублей стоит 12 ядерный 24 поточный 2678v3. И пусть задачи хоть обожрутся ядрами.
Кстати, оборотная сторона медали повышенной частоты - энергопотребление. Может лучше пусть ядра работают на 80% частоты, но жрут при этом (условно) вдвое меньше ?
mphys
02.01.2023 20:05+4Ага, только закон сохранения энергии вы не нарушите, и жрать они будут дольше, так что энергии вы почти не сэкономите, если машина рабочая. Если большую часть времени она в stand-by - то да, может быть.
valera5505
02.01.2023 20:14+8Да нет, энергию как раз существенно можно сэкономить. Как раз из-за того, что частота (и как следствие производительность) нелинейно растет от энергопотребления. Это очень наглядно видно по eco mode у Zen 4 процессоров.
NotSlow Автор
02.01.2023 20:11+22Да что ж никто не вникает в суть... Речь лишь про то, что не всягда все ядра одинаковы. И бывают ситуации, когда нужно получить максимум именно скорости. К примеру замер single-thread производительности в обычных условиях может пройти на турбо- и на не_турбо- ядрах с заметным отличием в результате. Или запускается что-то однопоточное очень очень долгое и вместо того чтоб довериться случаю, можно принудительно запустить это именно на чуть более быстром ядре. Либо наоборот, сделать чтоб гарантированно не влазили неважные процессы в быстрые ядра и чтоб с большей вероятностью что-то более важное выполнилось на них каплю быстрее.
Вот и все. Именно каплю, это чистый спорт, а не массовость. Всем это не надо. Тем более, что проблема далеко не глобальная и у большинства процессоров (пока еще) все ядра одинаковы.
Кому не интересно проходите мимо, никто не заставляет оставлять бессмысленный комментарий.
dolfinus
02.01.2023 21:21+4Недавно наткнулся на статью, где автор не только сталкивался с разной частотой ядер, но ещё и с тем, что у некоторых P ядер частота заметно колебалась, внося значительный шум (~25%) в результаты бенчмарков:
triky99
02.01.2023 21:33-5строить велосипеды ради 4%? увольте
ky0
02.01.2023 21:36+2А в чём тут велосипед? taskset же можно использовать не только ради распихивания по более крутым ядрам, но и более глобально — просто для управления Affinity.
triky99
02.01.2023 22:07-1потому что если нужно ручным управлением выжимать 4% и нет денег на железо, то это велосипед и колхоз
NotSlow Автор
02.01.2023 22:50+10Ок. Допустим нужно получить максимальную однопоточную скорость. Но денег нет и покупается лишь i9-13900k (А были бы деньги, вот тогда бы ого-го какой более быстрый можно было взять конечно).
Запускаем и получаем нашу задачу, работающую на 4.3 ГГц вместо 5.8
Дальше что?
ProFfeSsoRr
03.01.2023 18:21+1потому что если нужно ручным управлением выжимать 4%
Ну оно ручное, когда это 1 комп, и тот дома. А если таки серверов закупить хотя бы стойку, а руками-то надо 1 раз залезть, а потом на все серверы раскатать - получить 4% прироста на всю стойку это уже достаточно выгодно, когда серверы и так на последнем поколении процессоров и "просто апгрейдом" уже не решается.
edo1h
04.01.2023 06:59+1только вот получившаяся конфигурация получается куда менее универсальной.
придёт всплеск запросов на mysql, например, а он ограничен всего несколькими ядрами, и мы уже получим кратную потерю производительности.
Thomas_Hanniball
02.01.2023 22:22+10Судя по комментариям, статья принесла бы больше пользы, если бы в ней рассматривался реальный процессор с P и E ядрами, а не старый Xeon, где все ядра одинаковые. Там бы и разница была значительней, а также можно было посмотреть на работу Intel's Thread Director в Linux.
vodopad
02.01.2023 23:27+3https://www.thegeekdiary.com/how-to-set-cpu-affinity-for-systemd-process-in-centos-rhel-7/
А не лучше было бы использовать параметр CPUAffinity в systemd-unit вместо добавления taskset в ExecStart?NotSlow Автор
02.01.2023 23:48Службы - это частный случай опять же. Что-то же можно запустить просто так, не как службу.
max_dark
02.01.2023 23:37+2В нашем случае E-ядра - зло(нам нужна одинаковая производительность всех ядер).
Поэтому в планах переход с Intel -> AMD
BugM
02.01.2023 23:54+1На ксеонах разве есть е ядра?
У тредрипперов АМД свои проблемы. Если пара потоков неудачно уедет на разные ядра то легко можно словить минус 30% производительности. Дебажить первый раз довольно тяжело. Расселить виртуалки правильно тоже бывает непросто.
max_dark
03.01.2023 00:01У нас такая специфика, что мы используем процессоры для desktop.
Если конкретно, то мы поставляем аппаратно-программные комплексы. То есть ПО+железо.
BugM
03.01.2023 00:03Тогда в чем проблема? На десктопе всегда есть куча ерунды для е ядер. Мессенджер, музыка в фоне, текст кто-то печатает, что-то обновления проверить решило и все что угодно.
Посадить свою приложеньку на p ядра и не париться.
max_dark
03.01.2023 00:12Дело в себестоимости железа - купить 2 компьютера на Intel или 1 на AMD
BugM
03.01.2023 00:22Вы какие-то не те цены смотрите. Они одинаково стоят. Плюс-минус в зависимости от поставщика и ситуации на рынке прямо сейчас.
https://www.dns-shop.ru/product/0a2114a7fcc9ed20/processor-intel-core-i5-12400f-oem/
https://www.dns-shop.ru/product/3239ebce09e93332/processor-amd-ryzen-5-5600x-oem/
https://nanoreview.net/en/cpu-compare/intel-core-i5-12400f-vs-amd-ryzen-5-5600x
max_dark
03.01.2023 00:51Я говорил о полном комплекте для сборки ПК, а не только о процессоре.
Поставлять покупателю 2 современных ПК Intel VS 1 современный ПК AMD
ИМХО, мы выберем 2-й вариант, так как в этом случае себестоимость на полноценное ядро ниже.
Offtop: давайте закончим спор.
BugM
03.01.2023 01:04+3Да какой спор. Мне все еще интересно как вы умудряетесь собирать десктопы на АМД в два раза дешевле. При одинаковой стоимости процессоров и одинаковой стоимости всего остального.
Может я чего-то не знаю и переплачиваю в два раза? Покажите ссылочку на сборки в любом магазине.
VelocidadAbsurda
02.01.2023 23:38+9Интересно, а вот в мобильных устройствах (в том числе и под Android, у которого родственное Linux ядро) не первый год уже используются процессоры с гетерогенной компоновкой big.LITTLE, где разница в частотах ещё более ощутимая, и там выбор ядер планировщиком явно не случаен. По идее, должны существовать какие-то готовые автоматизированные софтовые решения данного вопроса. Или они на «большой» Linux не портировались?
lorc
03.01.2023 01:39+1Energy Aware Scheduling вошло в мейнлайн еще где-то в районе 2015 года
и Capacity Aware Scheduling поддерживается тоже довольно долго.Ну и у Интела конечно же NIH-синдром, так что будет еще Intel Thread Director в линуксе
ProFfeSsoRr
03.01.2023 18:24и там выбор ядер планировщиком явно не случаен
Так под андроид свои планировщики и существуют с самого его начала. Во время повального увлечения перепрошивками народ даже сам планировщики писал.
Или они на «большой» Linux не портировались?
Всё так. Ну точнее, не портировались, потому что условный "большой линукс" никто не запускает на условном Qualcomm'овском проце, под который кто-то написал планировщик на андроид (до недавнего времени, да и даже сейчас ноутбуков на ARM, которые не Apple, практически нет на рынке).
ShadowMaster
03.01.2023 00:24+7Так себе решение. ОС сама должна знать о ядрах процессора всё. Бывают ядра настоящие, а бывают полученные через HyperThreading/SMT. Из той же серии "двухядерные" модули AMD у которых общий FPU. Есть ядра с разных процессоров, есть с разных кластеров (например, CCD/CCX у AMD) и гонять задачи желательно внутри одного кластера. Есть ядра разных архитектур (big.LITTLE в ARM, P/E ядра в 12-13 сериях Интел), есть отборные ядра у Интел, которые могут бустится до больших частот. CCD/CCX у AMD тоже разные, некоторые могут достигать больших частот. Во втором ThreadRipper часть ядер вообще могла не иметь прямой доступ к памяти.
Да и вообще современные процессоры бустятся по температуре/TDP и частота зависит от нагрузки на все ядра и от характера этой нагрузки.
Привязывать же потоки к конкретным ядрам зло. ОС сама должна знать все эти перечисленные особенности и распределять нагрузку максимально эффективно.
NotSlow Автор
03.01.2023 00:42Поддерживаю. Но когда начнет знать и распределять, тогда и будет не актуально.
По правде особо не слежу, вроде в win11 что-то реализовано, но так понял слишком втупую - что на переднем плане, то на p ядрах, все что в фоне - на e ядрах. Свернул нужную задачу и она сильно замедлилась…
Знаете лучше решение, предлагайте.
Quark-Fusion
03.01.2023 14:53В Windows это настраиватся в параметрах системы. Можно убрать этот приоритет. И настройка была ещё до появления медленных ядер — по идее должна использваться.
NotSlow Автор
03.01.2023 00:52По сути ОС должна от части то же самое делать. Как-то определять список процессов, которые запускать лишь на e-ядрах и не тратить на них ни такта p-ядер т.к. в любой момент они могут потребоваться для чего-то более важного. Ну и плюс экономия энергии.
И также должна иметь некий приоритет ядер, чтоб тяжелые задачи первыми использовали только p-ядра. Но если вдруг понадобится больше, могла также запускать и на e-, но только при полной занятости p-
Либо если не знает сама ничего о процессоре и не может угадать нужд пользователя, то нужен какой-то инструмент для ручной расстановки приоритетов.
ShadowMaster
03.01.2023 01:21Информацию о процессоре ОС может иметь как непосредственно в ядре, так и получать через драйвер.
У ОС есть статистика о поведении разных процессов, сами разработчики могут явно или неявно давать подсказки ОС. Для десктопных ОС опять же активный процесс/фоновый процесс, возможность задать приоритет в диспетчере задач/свойствах запускаемого модуля. Но лучше это делать как совет ОС, железке виднее как все нужно распределить.
И я не вижу ничего плохого в использовании P-ядер фоновыми процессами, если P-ядра свободны.
И также должна иметь некий приоритет ядер, чтоб тяжелые задачи первыми использовали только p-ядра. Но если вдруг понадобится больше, могла также запускать и на e-, но только при полной занятости p-
Это не так. Если задача нормально параллелится, то запуск одновременно на P и E ядрах даст больше производительности, чем только на P-ядрах, даже если во втором случае частота P ядер выше. Сейчас все упирается в TDP/температуру.
BobArctor
03.01.2023 11:05Хорошая лабораторная работа, но не вздумайте пытаться рулить вручную ядрами на хоть сколько-то крупном продакшене. Пожалейте в первую очередь себя.
5exi
03.01.2023 11:55+1Потоки - это не ядра. Отключите hyper-threading на уровне BIOS и будет вам счастье. На высоко производительных задачах hyper-threading только мешает. На Вашем процессоре всего 4 ядра.
dimkrayan
03.01.2023 21:58на всякий случай предположение.
Может, это особенность конкретного экземпляра, а не платформы? Может, просто конкретные ядра такие?NotSlow Автор
03.01.2023 23:53Есть E5-1630v4 и E5-1650v4 - у обоих только 2 ядра могут 4.0, остальные 3.8
NotSlow Автор
04.01.2023 12:57
Вот такой же 6-ядерный. Тоже лишь пара 0/6 и 5/11 могут до 4.0. У остальных 3.8 потолок.
У меня нет, но уверен, что у 8-ядерного E5-1680 v4 картина будет та же. Не знаю как у E5-26xx v4 дела обстоят.
Также есть из следующего поколения W-2125 - там все ядра одинаковы. У более старых E3-12xx v3 тоже одинаково было.
DustCn
3.8Ггц это медленное, 4.0 это быстрое. Разница в 200Мгц или посчитаете в процентах, сколько это?
Сова и глобус.
NotSlow Автор
Конкретные цифры лишь для примера. Речь о самом факте - разная скорость ядер внутри одного процессора, о чем ОС не в курсе.
200 мало, ладно. А 4x3800 против 4x4000 уже более существенно. У другого процессора может быть другая разница, вы бы обозначили сразу порог когда начинает иметь значение. Вам может и 1.3 Ггц (5.2-3.9) у i9-12900k разница - не важна. Но не надо говорить за всех. Кому и 100 МГц будет иметь значение, для них и статья.
BugM
По простому все что меньше 10% это погрешность. И не стоит на нее обращать внимания.
NotSlow Автор
Это частный пример. Наверняка у более многоядерных процессоров разброс частот по-более 10%
Посещала мысль поменять процессор на E5-2696v4, у которого якобы максимум 3.7, а база лишь 2.2 - вот тут наверняка гораздо заметней было бы.
Было бы больше пользы, если б в комментариях просто делились статистикой частот по ядрам на других процессорах. Какая к примеру all core turbo у E5-2696v4 ? Информации ноль.
BugM
На самом деле на boost частотах все ядра сразу работать не могут. Обычно может только одно одновременно. И толку? В типичной серверной нагрузке это никак не поможет.
Измерения ради измерений получаются.
NotSlow Автор
Вы тоже не читая, сразу комментировать?
Могут! У E5-1650v4 к примеру 3.6 якобы базовая, 3.8 boost (относительно базовой же) когда все ядра одновременно загружены и до 4.0 могут лишь 4 вполне конкретных ядра, даже одновременно. Но если подключится еще и 5е ядро, то выше 3.8 уже не будет ни на каком.
А типичная серверная нагрузка - нет такого. Все очень индивидуально. Где постоянно высокое LA - можно не заморачиваться действительно, выше all core turbo не будет почти никогда. А если нагрузка средняя или низкая, то есть смысл заморочиться. Но зависит конечно от пофигизма владельца.
И главный вопрос - где взять информацию по all core turbo частотам разных cpu? Я не нашел нигде. Только по прошедшим через меня процессорам имею записи.
При выборе процессора, я хочу знать его верхний предел по частоте в 1 поток и нижний предел при полной нагрузке. А не какую-то там базовую, которая вообще нигде в реальности не будет фигурировать.
BugM
Да, не обратил внимания что вы про такое старье пишите. Этому процу уже на пенсию пора. Он по производительности на ватт только ест лишние деньги.
Нигде. Это теперь особенности реализации.
https://www.techpowerup.com/237740/on-intels-decision-to-no-longer-disclose-all-core-turbo
werter_l
Спасибо, оч познавательно.
Как раз темой cpu governer занялся, чтобы cpu не жрал в простое на proxmox ve.
Накопал такое:
CPUFreq Governors https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
intel_pstate CPU Performance Scaling Driver https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html
amd-pstate CPU Performance Scaling Driver https://docs.kernel.org/admin-guide/pm/amd-pstate.html
> Какая к примеру all core turbo у E5-2696v4 ? Информации ноль.
https://xeon-e5450.ru/socket-2011-3/e5-2600-v4/xeon-e5-2696-v4/
и там же:
https://xeon-e5450.ru/socket-2011-3/e5-2600-v3/
https://xeon-e5450.ru/socket-2011-3/e5-1600-v4/
https://xeon-e5450.ru/socket-2011-3/e5-2600-v4/
Хороший ресурс, рекомендую.
P.s. Proxmox, ceph, zfs, pfsense и все-все-все https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/
NotSlow Автор
Отлично. Т.е. у E5-2696v4 разброс от 3.7 до 2.8 - 900 МГц... тут выше носом вертели мол 200 МГц ни о чем.
DustCn
Это вы еще поядерный меморийный бандвизь не меряли. А на двухсокетном стандартном сервере, еще и дальний, по отношению к сетевому интерфейсу, процессор имеет увеличенную латентность.
А что - раз гулять так гулять!
GHofman
Вообще существует теорема Неймана:одно ядро, один процессор, одна шина. Вот и страдаем мы ,что нет нормализации и фирма IBM отказывается от выпуска персоналок, а вообще фреймов. Не может обеспечить гарантийное сопровождение продукции. Вообще производство многослойных структур я предлагал еще в 1983году будучи студентом4 курса мрти. Правда первая цель была производство гетероструктур. А охлаждение структур это просто лекционный материал. Например элементы Пельтье. А вообще знаю парня из хорошей научной семьи, которого перевели к нам чертить за замечание на оперативке, что именно то что выкидывают из схемы ради экономии для термостабилизации. Вот и слушай после этого Чехов:"стоит обнаружить плату-и можно с нее просто выкусить штук 5 советских микросхем".