> Да, тогда когда занятых работой потоков больше чем ядер.Это практически всегда так. На моём домашнем десктопе с 6 логическими ядрами, даже с незапущенным IIS и SQL Server, порядка 240 процессов и 4300 потоков. 0% ни на одно ядро я никогда не наблюдаю.
> Ему бы следовало мониторить активность задач, и заметить, что одна задача серьёзно занята чем-то и хочет сожрать столько процессорных квантов, сколько возможно,
Угу, он это и делает.
В Windows Server базовый квант времени (Quantum Reset) в 4 раза дольше, чем в Windows, специально чтобы снизить количество переключений контекста, но и в клиентских редакциях можно включить такой квант. В клиентских редакциях настоящий квант времени зависит от типа процесса: foreground/background, что тоже может продлевать квант времени. Также есть механизм Priority Boost, но он зависит от конкретной "single-threaded workload".
Когда заканчивается квант времени, почти всегда будет использован механизм, который позволяет просто продлить квант времени. Можно повысить приоритет (понизить niceness в Linux), тогда переключение потока на ядре будет ещё реже.
> суммарная производительность остальных ядер более чем в 100 раз больше, чем требуется остальным задачам
Очень опасное наблюдение, которое целиком опирается на неизменность нагрузки потоков (что, вообще говоря, очень большая редкость). Планировщик Windows записывает историю нагрузки, и использует её, но не на горячем пути планировщика, а в более редких/сложных ситуациях (см. далее).
> шедулить остальные задачи по свободным ядрам
Так и происходит, это свободные ядра сами делают (планировщик, запускаемый в их контексте).
Перекидывание может произойти в редком случае: все остальные потоки приоритета потока A и выше не готовы к выполнению. Чем "дальше" два ядра, тем меньше вероятность перекидывания (т.к. планировщик знает про конфигурацию ядер и итеративно расширяет поиск готовых к исполнению потоков, но до определённого порога, обычно границей является NUMA нода). Как видно из того же графика (опять, на нём нет даже масштаба времени), перекидывание практически всегда происходит между двумя (редко - тремя) ядрами (а в Zen 2 каждый CCX содержит 4 ядра!).
---
Почитал я про стандартный CFS (опирался на Wikipedia, https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-de.../ и на https://opensource.com/article/19/2/fair-scheduling-linux). Ни в коей мере не утверждаю правильность понимания, но следующий набор замечаний.
> The CFS scheduler has a target latency, which is the minimum amount of time—idealized to an infinitely small duration—required for every runnable task to get at least one turn on the processor.
> Of course, an idealized infinitely small duration must be approximated in the real world, and the default approximation is 20ms. Each runnable task then gets a 1/N slice of the target latency, where N is the number of tasks.
Немного (сильно) противоречит утверждению:
> сильно занятая задача будет "захватывать" ядро на несколько секунд за раз, а не на 40 миллисекунд в среднем.
Или это про то, что CFS будет всегда возвращать управление "сильно занятой задаче"? Но всё равно, что с остальными потоками в очереди? Никогда не получат ядро?
Далее вводится очень разумный концепт minimum granularity, затем знакомый термин virtual runtime (vruntime) (в Windows эта метрика более чёткая, в плане, на пару счётчиков больше).
> Suppose task T1 has run for its weighted 1/N slice, and runnable task T2 currently has the lowest virtual runtime (vruntime) among the tasks contending for the processor. The vruntime records, in nanoseconds, how long a task has run on the processor. In this case, T1 would be preempted in favor of T2.
> The scheduler tracks the vruntime for all tasks, runnable and blocked. The lower a task's vruntime, the more deserving the task is for time on the processor. CFS accordingly moves low-vruntime tasks towards the front of the scheduling line. Details are forthcoming because the line is implemented as a tree, not a list.
Но ведь это означает, что та самая "single-threaded workload" будет иметь очень большой vruntime и всегда оказываться далеко в "очереди" (которая на самом деле дерево) на исполнение, т.е. она всегда будет уступать более лёгким/быстрым (термин мой) потокам. Не проблема, но интересное замечание.
> Yet configurable scheduling domains can be used to group processors for load balancing or even segregation. If several processors share the same scheduling policy, then load balancing among them is an option; if a particular processor has a scheduling policy different from the others, then this processor would be segregated from the others with respect to scheduling.
В планировщике Windows это называется processor package, так что это знакомо.
Затем я открываю статью "The Linux Scheduler: a Decade of Wasted Cores", патчи из которой, как я слышал, были приняты в планировщик несколько лет назад. Интересный материал, затем я дохожу до этого момента:
> Now we have a new problem of balancing work across multiple runqueues.
> Suppose that one queue has one low-priority thread and another has ten high-priority threads.
> We could have each core check not only its runqueue but also the queues of other cores, but this would defeat the purpose of per-core runqueues.
Вот, серьёзное алгоритмическое отличие от планировщика Windows. Планировщик Windows полезет в очереди других ядер в порядке удалённости от текущего. В то время как CFS:
> Therefore, what Linux and most other schedulers do is periodically run a load-balancing algorithm that will keep the queues roughly balanced.
> Since load balancing is expensive the scheduler tries not to do it more often than is absolutely necessary. In addition to periodic load-balancing therefore, the scheduler can also trigger emergency load balancing when a core becomes idle.
Как я понимаю, Windows предпочитает балансировать нагрузку "здесь и сейчас", когда ядро готово войти в состояние простоя, а CFS выделяет это в отдельную регулярно запускающуюся рутину (с возможностью экстренного запуска как в Windows). Сравнивать лучше/хуже не буду, но отмечу, что подход CFS более предсказуем, в то время как планировщик Windows почти* всегда работает в контексте "надо прямо сейчас решить что дальше делать".
почти* - есть например отдельный алгоритм по борьбе с CPU Starvation и priority inversion, который работает вне контекста конкретного потока, но он асинхронный и работает как "консультант", рекомендуя правки к финальному решению планировщика Windows, опираясь на историю нагрузки каждого потока.
Сделаю вывод из прочитанного: Linux предпочитает простаивание ядер (если даже load balancing и перекинет все потоки кроме потока A на другие ядра), но удерживает (если load balancing так решит) потоки в пределах одной runqueue. Windows действует "жадно", решая, что лучше в каждый момент (но опираясь на историю в *некоторых* случаях), что может приводить к краже потоков, если эта кража дешёвая (внутри одного processor package, ибо более широкие поиски задействуются очень редко), а другой работы соответствующего приоритета нет. Это иногда случающееся перекидывание потоков имеет обоснование (снижение количества простаивающих ядер), но cache miss'ы могут случаться чаще (они весьма вероятны и на CFS, ибо если load balancing оставит хотя бы один другой поток на ядре, где выполняется поток A - точно так же будет борьба за L1 и L2 в течение каждого target granularity, а отношение ядер/потоков явно не в пользу ядер).
