Как изменить частоту переключения контекста в Linux?

Как можно изменить частоту переключения контекста в Linux (linaro, ubuntu, debian)?

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

EDIT1: у меня есть основной процесс, который я хочу запустить как можно быстрее (максимальное количество тактов в секунду), поэтому я подумал об уменьшении частоты переключения контекста (= увеличении временного интервала). Вопрос в том, как это сделать, и будет ли существенный эффект. Могу ли я рассчитать стоимость переключения контекста? То есть, могу ли я оценить, если я увеличу временной интервал в два раза, какой прирост моей производительности будет в% для основного процесса, который меня волнует?

Если ваша задача - единственный процесс, запрашивающий время на конкретном ЦП, контекстные переключения между задачами не будут :-). Но процессор все еще может прерываться, вызывая переключение контекста в ядро ​​и обратно. И одной из возможных причин является таймер упреждения, проверяющий, есть ли другая задача для запуска на этом процессоре ...

Linux может избежать генерации прерываний таймера с упреждением на процессоре, когда для этого не будет причин. См CONFIG_NO_HZ_FULL. Чтобы использовать эту функцию, она должна быть включена при сборке ядра и должна быть включена с помощью параметра загрузки.

• https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
• https://lwn.net/Articles/549580/ "(Почти) полная тикающая операция в 3.10"

По умолчанию, ни один процессор не будет процессором с адаптивными метками. Параметр загрузки «nohz_full =» указывает процессорные модули Adaptive-Ticks. Например, «nohz_full = 1,6-8» говорит, что процессоры 1, 6, 7 и 8 должны быть адаптивными. Обратите внимание, что вам запрещено помечать все процессоры как процессоры с адаптивной меткой [...]

LWN.net говорит, что «по словам Инго Молнара, для процессоров с адаптивными тактами будет сэкономлено до 1% времени ЦП». В документе ядра говорится, что это имеет шесть различных затрат, а также есть список «ИЗВЕСТНЫХ ПРОБЛЕМ».

Этот выигрыш относительно невелик, особенно по сравнению с потенциальным выигрышем в пропускной способности за счет уменьшения частоты переключений контекста между несколькими задачами, как указано в следующем ответе: Как изменить длину временных интервалов, используемых планировщиком ЦП Linux?

Мелкий шрифт: эти измерения предшествуют поддержке ASID Spectre, Meltdown, KPTI и x86 :-(. И я полагаю, они также применимы к более старому оборудованию. Спросите эксперта по ядру или проведите свои собственные измерения того, как стоимость контекстных переключателей изменилась ваша конкретная версия ядра и аппаратное обеспечение ... Предполагалось, что PTI в значительной степени смягчает PTI, за исключением программного обеспечения, которое очень часто вызывает ядро, главным примером являются базы данных, но я не очень хорошо разбираюсь в цифрах ,

Молнар надеялся, что в оригинальном RFC-патче со временем он «будет включен большинством дистрибутивов Linux». Я заметил, что Fedora 28 предоставляет ядро ​​по умолчанию, созданное с NO_HZ_FULLподдержкой. Однако Debian 9 этого не делает.

В последнее время Linux v4.17 удаляет остаточную частоту таймера 1 Гц из nohz_fullпроцессоров . Я полагаю, что влияние на пропускную способность довольно мало :-), но я пытался проследить за статусом NO_HZ_FULLпреимуществ, когда на процессоре есть несколько запущенных процессов -

как только мы достигнем 0 Гц, мы сможем [затем] удалить предположение о периодическом тике из nr_running> = 2, существенно прерывая занятые задачи только так часто, как этого требуют ограничения sched_latency - один раз каждые 4-40 мсек, в зависимости от nr_running ,

Это немного сбивает с толку, поскольку упреждение уже началось с использованием отдельного, более точного тика в v2.6.25-rc1, commit 8f4d37ec073c, "sched: тик с высоким разрешением" . Находится в этом комментарии к той же статье на LWN.net: https://lwn.net/Articles/549754/ ).