Планировщик Brain Fuck - Brain Fuck Scheduler

Планировщик Brain Fuck
Разработчики)	Кон Коливас
Окончательный релиз	0.512 / 3 октября 2016 г.; 4 года назад
Написано в	C
Операционная система	Linux
Лицензия	GNU GPL
Интернет сайт	ядро.kolivas.org

Расположение планировщики процессов в упрощенной структуре Ядро Linux

В Планировщик Brain Fuck (BFS) это планировщик процессов разработан для Ядро Linux в августе 2009 года в качестве альтернативы Полностью честный планировщик (CFS) и O (1) планировщик.^[2] BFS был создан опытным программистом ядра Кон Коливас.^[3]

Цель BFS, по сравнению с другими планировщиками, - предоставить планировщику более простой алгоритм, не требующий настройки эвристика или тюнинг параметры зашивать спектакль к определенному типу вычислительный нагрузка. Коливас утверждал, что эти настраиваемые параметры трудно понять обычному пользователю, особенно с точки зрения взаимодействия нескольких параметров друг с другом, и утверждал, что использование таких настраиваемых параметров часто может привести к повышению производительности в конкретном целевом типе вычислений. ценой худшей производительности в общем случае.^[3] Сообщается, что BFS улучшает скорость отклика на настольных компьютерах Linux с менее чем 16 ядра.^[4]

Вскоре после своего появления новый планировщик сделал заголовки в сообществе Linux, появившись на Slashdot, с обзорами в Журнал Linux и Журнал Linux Pro.^[2]^[5]^[6] Хотя были разные обзоры улучшенной производительности и отзывчивости, Кон Коливас не намеревался интегрировать BFS в основное ядро.^[3]

Теоретический дизайн и эффективность

В 2009 году была представлена BFS, первоначально использовавшая двусвязный список структура данных,^[7]^[8] но структура данных рассматривается как очередь. Вставка задачи есть О(1).^[8]^{:пер 119–120} Поиск задачи для следующей задачи О(п) худший случай.^[8]^{:пер 209} Он использует один глобальный очередь выполнения которые используют все процессоры. Задачи с более высоким приоритетом планирования выполняются первыми.^[8]^{:пер. 4146–4161} Задачи упорядочиваются (или распределяются) и выбираются на основе формулы виртуального крайнего срока во всех политиках, за исключением классов приоритета реального времени и изохронного приоритета.

Поведение исполнения по-прежнему является взвешенной вариацией Планировщик циклического перебора особенно, когда задачи имеют такой же приоритет ниже изохронной политики.^[8]^{:ln 1193–1195, 334–335} Настраиваемый пользователем интервал циклического перебора (отрезок времени ) по умолчанию составляет 6 миллисекунд, что было выбрано как минимальное дрожь чуть ниже обнаруживаемых людьми.^[8]^{:пер 306} Коливас утверждал, что все, что ниже 6 мс, бессмысленно, а все, что выше 300 мс для циклического временного интервала, бесполезно с точки зрения пропускной способности.^[8]^{:пер 314–320} Этот важный настраиваемый параметр может адаптировать планировщик циклического перебора как компромисс между пропускной способностью и задержкой.^[8]^{:пер. 229–320} Все задачи получают одинаковый временной интервал, за исключением FIFO в реальном времени, который, как предполагается, имеет бесконечный временной интервал.^[8]^{:пер. 1646, 1212–1218, 4062, 3910}

Коливас объяснил причину, по которой он решил использовать одинарную очередь с двусвязным списком, а не множественную очередь (циклический перебор).^[9]^{:пар. 3}) приоритетный массив^[10]^[9] на ЦП, который использовался в его планировщике RDSL, должен был упростить справедливость для сценария с несколькими ЦП и устранить сложность, которую каждая очередь выполнения в сценарии с несколькими очередями выполнения должна была поддерживать свои собственные задержки и справедливость [задачи].^[8]^{:ln 81–92} Он утверждал, что детерминированные задержки были гарантированы с помощью BFS в его более поздней версии MuQSS.^[11]^{:пер 471–472} Он также признал возможную проблему конфликта блокировок (связанную с изменением, удалением, созданием данных узла задачи)^[11]^{:пер 126–144} с увеличением ЦП и накладными расходами О(бревно п) следующая задача для поиска выполнения.^[11]^{:пер 472–478} MuQSS попытался решить эти проблемы.

Позже Коливас изменил дизайн на пропустить список в версии BFS v0.480 в 2016 году.^[12] На этот раз это изменило эффективность планировщика. Он отметил вставку задачи O (log n), поиск задачи O (1); O (k), с k <= 16, для удаления задачи.^[12]^{:пер 4}

Виртуальный дедлайн

Формула виртуального крайнего срока - это время будущего крайнего срока, которое представляет собой масштабированный временной интервал циклического перебора, основанный на смещении хорошего уровня на текущее время (в малых единицах или наносекундах. миг он же внутренний счетчик времени ядра).^[8]^{:пер. 4023, 4063} Виртуальный крайний срок только предлагает порядок, но не гарантирует, что задача будет выполняться точно в запланированное в будущем время.^[8]^{:пер. 161–163}

Сначала создается таблица поиска приоритетных соотношений.^[8]^{:пер. 8042–8044} Он основан на рекурсивной последовательности. Он увеличивается на 10% за каждый хороший уровень.^[8]^{:пер 161} Если он изображен на графике, он следует параболическому шаблону, и задачи с выделением распределены в виде скользящей функции в квадрате от 0 до 39 (соответствует от наивысшего до самого низкого приоритета) в качестве домена и от 128 до 5089 в качестве диапазона.^[8]^{:пер 177–179, 120, 184–185} Движущаяся часть исходит из ${ displaystyle t}$ переменная в формуле виртуального крайнего срока, на которую намекнул Коливас.

${ displaystyle g_ {0} = 128}$

${ displaystyle g_ {i} = ЦЕЛОЕ (g_ {i-1} * 11/10)}$

Индекс	Числитель
0	128
1	140
2	154
3	169
4	185
5	203
6	223
7	245
8	269
9	295
10	324
11	356
12	391
13	430
14	473
15	520
16	572
17	629
18	691
19	760
20	836
21	919
22	1010
23	1111
24	1222
25	1344
26	1478
27	1625
28	1787
29	1965
30	2161
31	2377
32	2614
33	2875
34	3162
35	3478
36	3825
37	4207
38	4627
39	5089

Задачи отлично функция отображения индекса ${ Displaystyle f (п)}$ преобразуется из nice -20… 19 в индекс 0… 39 для использования в качестве входных данных в поисковой таблице отношения приоритета. Эта функция отображения - это макрос TASK_USER_PRIO () в sched.h в заголовке ядра. Внутренняя реализация ядра немного отличается от диапазона статического приоритета 100–140, но пользователи увидят его как −20… 19.

Отлично	Индекс
−20	0
−19	1
−18	2
−17	3
−16	4
−15	5
−14	6
−13	7
−12	8
−11	9
−10	10
−9	11
−8	12
−7	13
−6	14
−5	15
−4	16
−3	17
−2	18
−1	19
0	20
1	21
2	22
3	23
4	24
5	25
6	26
7	27
8	28
9	29
10	30
11	31
12	32
13	33
14	34
15	35
16	36
17	37
18	38
19	39

Виртуальный дедлайн основан на этой точной формуле:^[8]^{:пер. 4063, 4036, 4033, 1180}

${ displaystyle T = 6}$

${ Displaystyle N = 1 << 20}$

${ Displaystyle d (N, T) = T + G (F (N)) * T * (N / 128)}$

В качестве альтернативы,

${ displaystyle d (n, t) = { frac {g (f (n))} {128}} * T * N + t}$

куда ${ Displaystyle д (п, т)}$ виртуальный крайний срок в u64 целых наносекундах как функция хорошего ${ displaystyle n}$ и ${ displaystyle t}$ которое является текущим временем в нюансах (как в наносекундах), ${ Displaystyle г (я)}$ поиск в таблице приоритетных соотношений как функция индекса, ${ Displaystyle f (п)}$ - это функция отображения правильного индексации задачи, ${ displaystyle T}$ интервал времени циклического перебора в миллисекундах, ${ displaystyle N}$ представляет собой константу 1 миллисекунду в единицах наносекунды как приближение, уменьшающее задержку, для коэффициента преобразования ${ displaystyle { frac {10 ^ {9} нс} {10 ^ {3} мс}}}$ но Коливас использует константу с основанием 2 ${ displaystyle N}$ примерно с таким масштабом.^[8]^:1173–1174 Меньшие значения ${ displaystyle d}$ означают, что виртуальный дедлайн раньше соответствует отрицательным значениям nice. Большие значения ${ displaystyle d}$ указывают, что виртуальный крайний срок сдвигается позже, что соответствует положительным значениям nice. Он использует эту формулу всякий раз, когда истекает временной интервал.^[8]^{:пер. 5087}

128 по основанию 2 соответствует 100 по основанию 10 и, возможно, «псевдо 100».^[8]^{:пер. 3415} 115 в базе 2 соответствует 90 в базе 10. Коливас использует 128 для "быстрого". сдвиги,"^[8]^{:пер. 3846, 1648, 3525} как в делении - база сдвига вправо 2.

* Альтернативная формула представлена для простоты понимания. Все вычисления выполняются в виде целых чисел, поэтому потеря точности была бы большой. Возможно, поэтому Коливас отложил деление на 128 до одного из наибольших чисел, кратного 128, что не дало остатка.

Отлично	Виртуальный дедлайн в временных интервалах относительно ${ displaystyle t}$	Виртуальный дедлайн в точных секундах относительно ${ displaystyle t}$
−20	1.0	0.006
−19	1.09	0.006562
−18	1.2	0.007219
−17	1.3	0.007922
−16	1.4	0.008672
−15	1.5	0.009516
−14	1.7	0.010453
−13	1.9	0.011484
−12	2.1	0.012609
−11	2.3	0.013828
−10	2.5	0.015187
−9	2.7	0.016688
−8	3.0	0.018328
−7	3.3	0.020156
−6	3.6	0.022172
−5	4.0	0.024375
−4	4.4	0.026812
−3	4.9	0.029484
−2	5.3	0.032391
−1	5.9	0.035625
0	6.5	0.039188
1	7.1	0.043078
2	7.8	0.047344
3	8.6	0.052078
4	9.5	0.057281
5	10.5	0.063000
6	11.5	0.069281
7	12.6	0.076172
8	13.9	0.083766
9	15.3	0.092109
10	16.8	0.101297
11	18.5	0.111422
12	20.4	0.122531
13	22.4	0.134766
14	24.7	0.148219
15	27.1	0.163031
16	29.8	0.179297
17	32.8	0.197203
18	36.1	0.216891
19	39.7	0.238547

Политики планирования

BFS использует политики планирования, чтобы определить, сколько задач ЦП может использовать. BFS использует 4 уровня планирования (называемых политиками планирования или классами планирования), упорядоченными от лучшего к худшему, что определяет способ выбора задач.^[8]^{:пер. 4146–4161} причем первыми выполняются те, что наверху.

Каждая задача имеет особое значение, называемое приоритетом. В редакции v0.462 (используемой в наборе исправлений ядра -ck 4.0) всего 103 «очереди приоритета» (также известные как prio) или допустимых значений, которые она может принимать. Никакая фактическая специальная структура данных не использовалась в качестве очереди приоритетов, а только сама очередь выполнения двусвязного списка. Более низкое значение prio означает, что оно более важно и выполняется первым.

Политика в реальном времени

Политика реального времени была разработана для в реальном времени задачи. Эта политика подразумевает, что выполняемые задачи не могут быть прерваны (т. Е. Вытеснены) задачей с более низким приоритетом или уровнями политики с более низким приоритетом. Классы приоритета, рассматриваемые планировщиком в рамках политики реального времени, - это классы, отмеченные SCHED_RR и SCHED_FIFO.^[8]^{:пер. 351, 1150} Планировщик по-разному обрабатывает циклический перебор в реальном времени (SCHED_RR) и FIFO реального времени (SCHED_FIFO).^[8]^{:пер. 3881–3934}

В проекте заложены первые 100 очередей со статическим приоритетом.^[8]^{:пер 189}

Задача, которая будет выбрана для выполнения, зависит от доступности задачи с наименьшим значением приоритета из 100 очередей и планирования FIFO.^[8]^{:пер. 4146–4161}

На вилки, приоритет процесса будет понижен до нормальной политики.^[8]^{:пер. 2708}

При непривилегированном использовании (то есть пользователем без полномочий root) sched_setscheduler, вызываемого с запросом класса политики реального времени, планировщик понижает задачу до изохронной политики.^[8]^{:пер 350–359, 5023–5025}

Изохронная политика

Изохронная политика была разработана для обеспечения производительности почти в реальном времени для не-корень пользователей.^[8]^{:пер. 325}

В проекте предусмотрена 1 приоритетная очередь, которая по умолчанию запускается как задачи псевдо-реального времени, но может быть настроена как степень реального времени.^[8]^{:пер 1201, 346–348}

Поведение политики позволяет перевести задачу в режим нормальной политики.^[8]^{:пер. 336} когда он превышает настраиваемый процент обработки ресурсов (70% по умолчанию^[8]^{:пер. 343, 432}) 5 секунд, масштабируемых по количеству онлайн-процессоров и разрешению таймера плюс 1 тик.^[8]^{:пер. 343, 3844–3859, 1167, 338}^[11]^{:ln 1678, 4770–4783, 734} Формула была изменена в MuQSS из-за дизайна с несколькими очередями выполнения. Точные формулы:

${ Displaystyle T_ {BFS} = ((5 * F * n) +1) * R}$
${ displaystyle T_ {MuQSS} = (5 * F) * R}$

куда ${ displaystyle T}$ - общее количество изохронных тактов, ${ displaystyle F}$ частота таймера, ${ displaystyle n}$ количество онлайн-процессоров, ${ displaystyle R}$ - настраиваемый процент обработки ресурса не в десятичном формате, а в виде целого числа. Частота таймера по умолчанию установлена на 250 и редактируется в ядре, но обычно настраивается на 100 Гц для серверов и 1000 Гц для интерактивных рабочих столов. 250 - это сбалансированное значение. Параметр ${ displaystyle R}$ до 100 заставляло задачи вести себя как в реальном времени, а 0 делало их не псевдо-реальным временем, а все, что в середине, было псевдо-реальным временем.^[8]^{:пер. 346–348}

Для выполнения была выбрана задача, у которой был самый ранний виртуальный крайний срок, но когда существует несколько изохронных задач, они планируются как циклический перебор, позволяющий задачам запускать настраиваемое значение циклического перебора (с 6 мс по умолчанию) одну за другой на ярмарке. равные шансы без учета хорошего уровня.^[8]^{:пер. 334}

Такое поведение изохронной политики уникально только для BFS и MuQSS и не может быть реализовано в других планировщиках ЦП.^[8]^{:пер. 324, 8484–8485}^[11]^{:пер. 1287–1288}

Нормальная политика

Обычная политика была разработана для регулярного использования и является политикой по умолчанию. Вновь созданные задачи обычно помечаются как обычные.^[8]^{:пер 502}

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

Политика приоритета простоя

Приоритет простоя был разработан для фоновых процессов, таких как распределенные программы и транскодеры так что процессы переднего плана или процессы, находящиеся выше этой политики планирования, могут работать бесперебойно.^[8]^{:пер. 363–368}

В дизайне выложена 1 приоритетная очередь и задачи могут быть продвинутый к нормальной политике автоматически, чтобы предотвратить бессрочное удержание ресурса.^[8]^{:пер. 368}

Следующая выполняемая задача с приоритетом простоя с другими, находящимися в той же политике приоритета, выбирается к самому раннему виртуальному крайнему сроку.^[8]^{:ln 4160–4161}

Упреждение

Упреждение может произойти, когда новая готовая задача с политикой более высокого приоритета (т.е. более высокая приоритетность) имеет более ранний виртуальный крайний срок, чем текущая выполняющаяся задача, которая будет отменена и помещена в конец очереди.^[8]^{:пер 169–175} Запланировано означает, что его виртуальный крайний срок обновлен.^[8]^{:пер 165–166} Время задачи пополняется до максимального кванта циклического перебора, когда оно израсходовано все свое время.^[8]^{:пер. 4057–4062, 5856} Если планировщик обнаружил задачу с более высокой приоритетностью и самым ранним виртуальным крайним сроком, она будет выполняться вместо менее важной в настоящее время выполняющейся задачи только в том случае, если все логические процессоры (включая ядра с гиперпоточностью / потоки SMT) заняты. Планировщик будет задерживать приоритетное прерывание как можно дольше, если есть неиспользуемые логические ЦП.

Если задача помечена политикой приоритета бездействия, она не может вообще вытеснять даже другие задачи, отмеченные политикой бездействия, а скорее использовать совместная многозадачность.^[8]^{:пер. 2341–2344}

Размещение задачи, несколько ядер

Когда планировщик обнаруживает задачу пробуждения, ему необходимо определить, какой логический ЦП будет запускать задачу пробуждения в системе, отличной от unicore. Планировщик больше всего отдает предпочтение бездействующим гиперпотоковый ядра (или простаивают SMT потоков) сначала на том же процессоре, на котором выполнялась задача,^[8]^{:пер. 261} затем другое простаивающее ядро многоядерного процессора,^[8]^{:пер 262} затем другие процессоры на том же узле NUMA,^[8]^{:ln 267, 263–266, 255–258} тогда все занятые гиперпоточные ядра / потоки SMT / логические процессоры будут вытеснены на одном и том же NUMA узел,^[8]^{:пер. 265–267} затем другой (удаленный) узел NUMA^[8]^{:пер. 268–270} и входит в список предпочтений.^[8]^{:пер 255–274} Это специальное сканирование предназначено для минимизации накладных расходов, связанных с задержкой при переносе задачи.^[8]^{:пер. 245, 268–272}

Порядок вытеснения аналогичен приведенному выше абзацу. Порядок вытеснения - сначала гиперпоточное ядро / блоки SMT на одном и том же многоядерном ядре, затем другое ядро в многоядерном процессоре, а затем другой ЦП на том же узле NUMA.^[8]^{:пер. 265–267} Когда он сканирует задачу для вытеснения на другом удаленном узле NUMA, вытеснение - это просто любые занятые потоки с меньшим или равным приоритетным или более поздним виртуальным крайним сроком, предполагая, что все логические процессоры (включая гиперпоточное ядро / потоки SMT) на машине все занятый.^[8]^{:пер 270} Планировщик должен будет сканировать подходящую задачу с задачей политики с более низким или, возможно, равным приоритетом (с более поздним виртуальным крайним сроком, если необходимо), чтобы вытеснить и избежать логических процессоров с задачей с политикой более высокого приоритета, которую он не может вытеснить. Локальное вытеснение имеет более высокий ранг, чем сканирование удаленного незанятого блока NUMA.^[8]^{:пер. 265–269}

Когда задача принудительно прерывается в то время, когда ЦП замедляется в результате опосредованного ядром Масштабирование частоты процессора (он же регулятор частоты процессора), задача помечается как «липкая», за исключением тех, которые помечены как политика реального времени.^[8]^{:пер 2085} Отмечено как закрепленное, что указывает на то, что у задачи еще есть неиспользованное время, и выполнение задачи ограничено одним и тем же процессором.^[8]^{:пер. 233–243} Задача будет помечена как «липкая», если регулятор масштабирования ЦП масштабировал ЦП на более низкой скорости.^[8]^{:ln 2082–2107, 8840–8848} Прикрепленная задача на холостом ходу либо вернется к выполнению на полной скорости ГГц, либо будет перепланирована для выполнения на лучшем простаивающем ЦП, который не является тем же ЦП, на котором выполнялась задача.^[8]^{:ln 2082–2086, 239–242, 2068–2079} Нежелательно переносить задачу в другие места, а вместо этого делать ее неактивной из-за увеличения задержки, вызванной накладными расходами при переносе задачи на другой ЦП или узел NUMA.^[8]^{:пер 228, 245} Эта липкая функция была удалена в последней версии BFS (v0.512), соответствующей патчу 4.8-ck1 Коливаса, и не существовала в MuQSS.

schedtool

Привилегированный пользователь может изменить политику приоритетов процесса с помощью программы schedtool.^[8]^{:пер. 326, 373} или это делается самой программой.^[8]^{:пер. 336} Классом приоритета можно управлять на уровне кода с помощью системный вызов как sched_setscheduler доступен только для root,^[13] который использует schedtool.^[14]

Контрольные точки

В современном исследовании^[4] автор сравнил BFS с CFS с использованием ядра Linux v3.6.2 и нескольких конечных точек, основанных на производительности. Целью этого исследования было оценить полностью справедливый планировщик (CFS) в ваниль Ядро Linux и BFS в соответствующем ядре с исправлениями ck1. Было использовано семь разных компьютеров, чтобы увидеть, существуют ли различия и в какой степени они масштабируются с использованием показателей, основанных на производительности. Число логических процессоров варьировалось от 1 до 16. Эти конечные точки никогда не были факторами в основных целях проектирования BFS. Результаты были обнадеживающими.

Ядра, исправленные с помощью набора исправлений ck1, включая BFS, превзошли ванильное ядро, использующее CFS, почти во всех тестируемых тестах производительности.^[4] Можно было бы провести дальнейшее исследование с большим набором тестов, но на основе небольшого набора тестов из 7 оцененных ПК, это увеличение очереди процессов, эффективность / скорость в целом не зависит от типа процессора (моно, двойной, четырехъядерный, гиперпоточный. и т. д.), архитектуру ЦП (32- и 64-разрядную) и множественность ЦП (моно или двухпроцессор).

Более того, на некоторых «современных» процессорах, таких как Intel Core 2 Duo и Core i7, которые представляют собой обычные рабочие станции и ноутбуки, BFS стабильно превосходила CFS в ванильном ядре на всех тестах. Прирост эффективности и скорости был небольшим или умеренным.

Принятие

BFS - это планировщик по умолчанию для следующих настольных дистрибутивов Linux:

Кроме того, BFS был добавлен в экспериментальную ветку Google с Android репозиторий разработки.^[19] Он не был включен в Релиз Froyo после слепое тестирование не показал улучшенного взаимодействия с пользователем.^[20]

MuQSS

BFS был отправлен на пенсию в пользу MuQSS, формально известный как Планировщик множественных очередей Skiplist, переписанная реализация той же концепции.^[21]^[22]

Теоретический дизайн и эффективность

MuQSS использует двунаправленную статическую матрицу 8 уровней пропустить список а задачи упорядочены по статическому приоритету [очереди] (ссылаясь на политику планирования) и виртуальному крайнему сроку.^[11]^{:пер. 519, 525, 537, 588, 608} 8 был выбран для размещения массива в строке кэша.^[11]^{:пер 523} Для ускорения удаления задачи был выбран дизайн двусвязной структуры данных. Удаление задачи занимает всего О(1) с двойным списком пропуска по сравнению с оригинальным дизайном Уильям Пью который берет О(п) худший случай.^[11]^{:пер 458}

Вставка задачи есть О(бревно п).^[11]^{:пер 458} Следующая задача для поиска выполнения - О(k), куда k количество процессоров.^[11]^{:пер. 589–590, 603, 5125} Следующее задание к исполнению: О(1) на очередь выполнения,^[11]^{:ln 5124} но планировщик проверяет все остальные очереди выполнения, чтобы поддерживать справедливость задач между ЦП, задержку или балансировку (чтобы максимизировать использование ЦП и согласованность кеша на одном и том же узле NUMA по сравнению с теми, которые обращаются через узлы NUMA), поэтому в конечном итоге О(k).^[11]^{:ln 591–593, 497–501, 633–656} Максимальное количество задач, которые он может обрабатывать, составляет 64 тыс. Задач на очередь выполнения на процессор.^[11]^{:пер. 521} В некоторых конфигурациях он использует несколько очередей выполнения задач, по одной очереди выполнения на ЦП, тогда как его предшественник BFS использовал только одну очередь выполнения задач для всех ЦП.

Задачи упорядочены по градиенту в списке пропусков таким образом, что приоритет политики в реальном времени идет первым, а приоритет политики бездействия - последним.^[11]^{:пер. 2356–2358} Нормальная политика приоритета и политика простоя по-прежнему сортируются по виртуальному крайнему сроку, который использует отлично значения.^[11]^{:пер 2353} Задачи политики в реальном времени и изохронные запускаются в ФИФО порядок игнорирования хороших значений.^[11]^{:пер. 2350–2351} Новые задачи с тем же ключом размещаются в порядке FIFO, что означает, что новые задачи помещаются в конец списка (то есть на самый верхний узел по вертикали), а задачи на 0-м уровне или на переднем нижнем уровне выполняются первыми перед теми, которые находятся ближе всего к сверху вертикально и дальше всего от головного узла.^[11]^{:пер. 2351–2352, 590} Ключ, используемый для вставленной сортировки, имеет статический приоритет.^[11]^{:пер. 2345, 2365, г.} или виртуальный крайний срок.^[11]^{:пер 2363}

Пользователь может выбрать совместное использование очередей выполнения для многоядерных процессоров или создание очереди выполнения для каждого логического процессора.^[11]^{:пер. 947–1006} Предполагалось, что совместное использование очередей выполнения должно уменьшить задержку за счет снижения пропускной способности.^[11]^{:пер. 947–1006}

Новым поведением, введенным MuQSS, было использование таймера с высоким разрешением для точности ниже миллисекунды, когда временные интервалы были использованы, что привело к изменению расписания задач.^[11]^{:пер. 618–630, 3829–3851, 3854–3865, 5316}

Смотрите также

Планирование справедливого распределения

внешняя ссылка

Brain Fuck Scheduler FAQ

[1] "-ck взлом: BFS версия 0.512, linux-4.8-ck1, MuQSS для linux-4.8". ck-hack.blogspot.com. 2016-10-03. Получено 2016-11-10.

[Linux_Pro_Magazine_on_BFS-2] а ^б «Кон Коливас представляет новый планировщик BFS» Linux Magazine ». Linuxpromagazine.com. 2009-09-02. Получено 2013-10-30.

[bfsfaq-3] а ^б ^c "Часто задаваемые вопросы о BFS v0.330". Ck.kolivas.org. Получено 2013-10-30.

[shedulers_compared-4] а ^б ^c «Сравнение планировщиков ЦП» (PDF). Repo-ck.com. Получено 2013-10-30.

[5] "Con Kolivas Returns, с настольным планировщиком Linux". Slashdot. Получено 2013-10-30.

[6] «Инго Молнар тестирует новый планировщик BF». Журнал Linux. 2009-09-08. Получено 2013-10-30.

[sched-bfs-001.patch-7] "sched-bfs-001.patch". Кон Коливас. 2009-08-13. Получено 2020-10-09.

[4.0-sched-bfs-462.patch-8] а ^б ^c ^d ^е ^ж ^грамм ^час ^я ^j ^k ^л ^м ^п ^о ^п ^q ^р ^s ^т ^ты ^v ^ш ^Икс ^у ^z ^аа ^ab ^ac ^{объявление} ^ае ^аф ^аг ^ах ^ай ^эй ^ак ^аль ^{являюсь} ^ан ^ао ^ap ^водный ^ар ^{в качестве} ^в ^au ^{средний} ^ау ^топор ^ай ^az ^ба ^bb ^{до н.э} ^bd ^быть ^парень ^bg ^бх "4.0-sched-bfs-462.patch". Кон Коливас. 2015-04-16. Получено 2019-01-29.

[lwn-224865-9] а ^б «Планировщик крайних сроков вращающейся лестницы». корбет. 2007-03-06. Получено 2019-01-30.

[10] "sched-rsdl-0.26.patch". Кон Коливас. Архивировано из оригинал на 2011-07-26. Получено 2019-01-30.

[0001-MultiQueue-Skiplist-Scheduler-version-v0.173.patch-11] а ^б ^c ^d ^е ^ж ^грамм ^час ^я ^j ^k ^л ^м ^п ^о ^п ^q ^р ^s ^т ^ты ^v "0001-MultiQueue-Skiplist-Scheduler-version-v0.173.patch". Кон Коливас. 2018-08-27. Получено 2019-01-29.

[4.7-sched-bfs-480.patch-12] а ^б "4.7-sched-bfs-480.patch". Кон Коливас. 2016-09-02. Получено 2020-10-09.

[13] «Планировщик Linux». Моше Бар. 2000-04-01. Получено 2019-01-29.

[14] "schedtool.c". бесплатно. 2017-07-17. Получено 2019-01-30.

[15] «Сабайон 7 приносит рай для Linux». Ostatic.com. Получено 2013-10-30.

[16] «Выпуск 2010 доступен для скачивания». PCLinuxOS. 2013-10-22. Получено 2013-10-30.

[17] «Zenwalk 6.4 готов! - Выпуски - Новости». Zenwalk.org. Архивировано из оригинал в 2013-10-23. Получено 2013-10-30.

[18] «О GalliumOS - GalliumOS Wiki». wiki.galliumos.org. Получено 2018-06-08.

[19] [1] В архиве 22 сентября 2009 г. Wayback Machine

[20] «CyanogenMod 5 для G1 / ADP1». Lwn.net. Получено 2013-10-30.

[bfsretired-21] "ck-hacking: linux-4.8-ck2, версия MuQSS 0.114". ck-hack.blogspot.com. 2016-10-21. Получено 2016-11-10.

[phoronix-MuQSS-22] ttps://www.phoronix.com/scan.php?page=news_item&px=MuQSS-First-Major-Release

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

Linux
Ядро Linux	История Ядро Закон Линуса Linux-libre Процесс запуска Linux Ядро Linux упс Смокинг более…
Споры	Критика Linux Критика настольного Linux Споры об именах GNU / Linux Дебаты Таненбаума и Торвальдса SCO и Linux
Распределения	Общее сравнение Список дистрибутивов Сравнение конкретных нетбуков Дистрибутивы, запускаемые из ОЗУ Легкий Операционная система, ориентированная на безопасность Проприетарное ПО для Linux Менеджер пакетов Формат упаковки Список менеджеров программных пакетов
Организации	LinuxChix Счетчик Linux Проект документации Linux Linux Foundation Linux Mark Institute Группа пользователей Linux (LUG)
Принятие	Усыновители Рабочий стол Встроенный Игры Мобильный Диапазон использования
Средства массовой информации	DistroWatch Журнал свободного программного обеспечения Полный круг Linux.com Формат Linux Linux Gazette Linux журнал Журнал Linux LinuxUser Пользователь Ubuntu Linux Outlaws Голос Linux LugRadio LWN.net Открытый исходный код для вас Фороникс ОС Revolution Код
Категория Портал

Планировщик Brain Fuck - Brain Fuck Scheduler

Содержание

Теоретический дизайн и эффективность

Виртуальный дедлайн

Политики планирования

Политика в реальном времени

Изохронная политика

Нормальная политика

Политика приоритета простоя

Упреждение

Размещение задачи, несколько ядер

schedtool

Контрольные точки

Принятие

MuQSS

Теоретический дизайн и эффективность

Смотрите также

Рекомендации

внешняя ссылка