LINUX.ORG.RU

Con Kolivas вернулся: встречайте BFS

 , , ,


0

0

Con Kolivas вернулся с новым планировщиком задач для Линукс ядра BFS (Brain Fuck Scheduler). Цитата:

Почему я написал его?

После многих лет использования моего старого ядра [Линукса] и многочисленных обновлений железа, в конце концов у меня появилось оборудование, которое требовало новых драйверов ядра, а также мне хотелось попробовать новые файловые системы. Загрузка в стандартное ядро [основная ветка на kernel.org] была достаточно обнадёживающей в том, что поведение планировщика стало гораздо лучше, чем в старых ядрах. Однако, много времени не потребовалось, чтобы я разочаровался и в этом [планировщике]. Случайные зависания при движении курсора мыши и нажатиях клавиш, странное распределение процессорного времени при разных вариантах нагрузки на систему и непредсказуемое поведение - это всё то, что, я надеялся, уже исправили. Поэтому я сделал то, чего поклялся никогда не делать - изучил код [планировщика CFS в ядре]. Увидев, что он превратился в монстра невероятных размеров, я сел и поразмыслил, что же в нём не так.

Одна из основных особенностей "справедливости" и интерактивности, за которую я всегда ратовал — это простая семантика того, как должно распределяться процессорное время; с гарантированными низкими задержками так, чтобы интерактивность была гарантирована архитектурой системы, а не так, чтобы она была привинчена с краю [bolted on]. По сути CFS так и делает, но у CFS есть кое-что ещё. CFS варьирует отрезки времени с тем, чтобы попытаться сохранить список завершения задач и определяет распределение процессорного времени, основываясь на отношении работы, поделённой на отдых. CFS также спроектирован, чтобы работать на супер-компьютерах - то, что обычный человек никогда даже не увидит.

Все эти подсчёты времени сна - это то, что, как я обнаружил, ответственно за различное поведение системы при различных нагрузках на неё - то, что вызывает относительное "голодание" и нечестность распределения процессорного времени. Хотя, надо отдать должное, в CFS это не сильно выражено, и это замечательно. Но, тем не менее, поведение системы при работе CFS - это не то ощущение, которое я бы хотел получить при работе планировщика. Правильный планировщик должен "думать" только о будущем (не подсчитывая время сна), а CFS, увы, не загружает полностью достаточно ненагруженную систему с небольшим количеством процессоров.

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

Что же это такое?

BFS - это аббревиатура от Brain Fuck Scheduler (позволю себе оставить без перевода). Он был разработан по принципу "гляжу только вперёд" и позволяет выжать максимум из достаточно слабых компьютеров, при этом он не ориентирован на суперкомпьютеры. BFS ориентирован на десктоп, имеет при этом по дизайну сверхнизкие задержки для великолепной интерактивности, вместо того, чтобы заниматься подсчётами, при этом BFS имеет настоящую "честность" (распределения процессорного времени), хорошее распределение уровней NICE и отличную масштабируемость при обычных нагрузках.

Отличная масштабируемость при обычных нагрузках? Разве тут нет противоречия?

Многие годы мы нагружали свои Linux системы так, чтобы работы было больше, чем у нас есть процессоров, потому что все мы считали, что jobservers ограничены в своих способностях по полному использованию процессоров (поэтому на 4х процессорном компьютере мы запускали компиляцию в шесть потоков). Мой планировщик доказал, что jobserver ни в чём не виноват, потому что на компьютере с 4 процессорами четыре потока при использовании BFS завершают работу быстрее, чем *любое* количество jobserver'ов при использовании CFS. Предлагаю вам посмотреть на графики обратной масштабируемости Сергея Беляшева, показывающие нагрузку на систему при разном количестве "задач" (jobs) на 4х ядерном компьютере. Планировщик задач в основном ядре никогда не может нагрузить машину полностью - он не может выжать максимум из вашей настольной системы ни при каких обстоятельствах. Отмечу, что этот график достаточно стар - масштабируемость с тех пор улучшилась.

Далее Кон объясняет выбор его имени (потому что, скорее всего, этот планировщик никогда не появится в основном ядре, и BFS не ориентирован на супер-компьютеры, например, на NUMA машины) и даёт рекомендации по его использованию (просто наложите патч на ядро).

>>> BFS Faq

★★★★★

Проверено: boombick ()

Ответ на: комментарий от Relan

> NUMA -- это любая многосокетная система, имеющая процессоры с интегрированным контроллером памяти.

Э? Нет.

sv75 ★★★★★
()
Ответ на: комментарий от Relan

>NUMA -- это любая многосокетная система, имеющая процессоры с интегрированным контроллером памяти. То есть все многосокетные системы от AMD и новые от Intel (те что на Nehalem). Какие нафиг суперкомпьютеры?

NUMA предполагает раздельное адресное пространство. Где ты такое видел в SMP системах?

AVL2 ★★★★★
()
Ответ на: комментарий от Deleted

>> Что лучше:
>> 1) "Масштабируемость" через редактирование исходников (патченье)


под Масштабируемостью я понимаю немного другое - возможность установки ядра не только на десктопах , а также на супер-компьютерах , с учетом динамического наращивания мощности
насколько я знаю , кластеры в основном работают под линуксом

kto_tama ★★★★★
()
Ответ на: комментарий от Relan

>Переключаться между ними в run time нельзя -- только пересобирать ядро.

Orly? Я в грабовском menu.lst прописываю опцию ядра и ничего не пересобираю

yoghurt ★★★★★
()
Ответ на: комментарий от Deleted

>И это плохо. И мейнтейнеры дистрибутивов это знают. И они продвигают свои патчи в апстрим.

Эмм рассмотрим проблему философского плана. Узкоспециализированная система лучше широко специализированной на узком круге задач. В большинстве случаев нельзя получить систему общего назначения не пойдя на компромиссы. Мне не нужна система общего назначения. Я хочу специализированный сервер и специализированный десктоп. Общий у них должен быть интерфейс, а не реализация.

Теже РТ патчи не включены во все ядра, как и ядра с OpenVR идут отдельно ибо не всем это надо, а пихание всего и вся создает трудности в поддержке.

TyhDyh
()
Ответ на: комментарий от Turbid

> Колинза

Коливас.

> как у бывшего анестезиолога


Разве он бывший анастезиолог, а сейчас кем-то другим работает?

> Выкинуть никогда не поздно будет.


Ещё раз. Планировщик процессов - это одна из важнейших частей любой многозадачной ОС. Драйвер для USB-фаллоимитатора можно включить в ядро, когда Вася Пупкин его напишет, а потом выкинуть, когда интерфейсы в ядре поменяются, и окажется, что Вася Пупкин уже сломал дейвайс или потерял к нему интерес, так что исправить код некому. Планировщик нельзя в одной версии ядра включить, а в другой просто взять и выкинуть.

Deleted
()
Ответ на: комментарий от Reset

> Что мешает сделать несколько планировщиков ?

Наверное только (не)желание разработчиков.

4 планировщика ввода/вывода уже есть и никому это не мешает.

vadiml ★★★★★
()
Ответ на: комментарий от AVL2

> NUMA предполагает раздельное адресное пространство. Где ты такое видел в SMP системах?

o_O Какое адресное пространство? NUMA подразумевает, что для доступа к некоторым участкам памяти используется чужой контроллер памяти, что замедляет работу с такой памятью раза в полтора-два.

mv ★★★★★
()
Ответ на: комментарий от Deleted

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

Turbid ★★★★★
()
Ответ на: комментарий от TyhDyh

> Эмм рассмотрим проблему философского плана. Узкоспециализированная система лучше широко специализированной на узком круге задач. В большинстве случаев нельзя получить систему общего назначения не пойдя на компромиссы. Мне не нужна система общего назначения. Я хочу специализированный сервер и специализированный десктоп. Общий у них должен быть интерфейс, а не реализация.

Именно поэтому некоторые свойства ядра можно изменить только перекомпиляцией с новыми опциями.

Если бы мейнтейнеры дистрибутивов не отправляли патчи в апстрим или разработчики ядра не исправляли другим способом проблемы, найденные мейнтейнерами, то количество патчей бы постоянно росло и фактически получилась бы куча форков ядра, не совместимых друг с другом. Это вообще недопустимо.

> Теже РТ патчи не включены во все ядра


Я не с проста выше кинул ссылку на архив с RT-патчами. Смысл в том, что они постепенно переходят в ванильное ядро. И через какое-то время этих патчей вообще не будет - достаточно будет тукнуть галочку в make xconfig.

> а пихание всего и вся создает трудности в поддержке.


Наоборот.

Deleted
()
Ответ на: комментарий от yoghurt

>Orly? Я в грабовском menu.lst прописываю опцию ядра и ничего не пересобираю

Ты, наверное, прописываешь планировщик ввода-вывода

ttnl ★★★★★
()

> BFS - это аббривеатура от Brain Fuck Scheduler (позволю себе оставить без перевода).

Мозгоклюйный планировщик. :)

P.S. Предлагаю показать мощь ЛОРа и коллективным бессознательным создать JWS ("Just Work" Scheduler). Думаю, мощь libastral позволить оставить позади BFS, выжав из процессора более 100%. ;-)

atrus ★★★★★
()
Ответ на: комментарий от Relan

>NUMA -- это любая многосокетная система, имеющая процессоры с интегрированным контроллером памяти. То есть все многосокетные системы от AMD и новые от Intel (те что на Nehalem). Какие нафиг суперкомпьютеры?

Ты много знаешь людей у которых десктоп на NUMA? Кого больше, тех у кого обычный десктоп и они были бы рады большей отзывчивости системы или тех у кого Numa?

Robotron
()
Ответ на: комментарий от Deleted

Вы хотите сказать что предпочли бы Microsoft Windows Mobile Edition не толькона телефоне, но и на десктопе и на сервере и на кластерах? :)

eugene2k
()
Ответ на: комментарий от eugene2k

> Вы хотите сказать что предпочли бы Microsoft Windows Mobile Edition не толькона телефоне, но и на десктопе и на сервере и на кластерах? :)

Я хотел скачать, что предпочёл бы на всех девайсах одно и то же ядро, собираемое из одних и тех же универсальных исходников, но с разным конфигом сборки или настройками, применяемыми во время загрузки системы. Как-то так.

Deleted
()
Ответ на: комментарий от Deleted

А ядро там ведь не во всех системах совершенно разное. Сервер, десктоп, и, вероятно кластер работают скорее всего на одном ядре. Мобайл работает на другом ядре, но мсовцы ее сейчас собираются пристрелить и следующая мобайл вроде будет на стандартном ядре.

eugene2k
()
Ответ на: комментарий от Deleted

> Что лучше:
> 1) "Масштабируемость" через редактирование исходников (патченье)

> 2) Через пересборку ядра с новыми опциями

> 3) Через изменение параметра работающего ядра в реальном времени

> ?


Хватит и изменения параметра в конфиг-файле с последующей перезагрузкой компа.

xintrea
()
Ответ на: комментарий от Robotron

> Ты много знаешь людей у которых десктоп на NUMA? Кого больше, тех у кого обычный десктоп и они были бы рады большей отзывчивости системы или тех у кого Numa?

Это да, согласен.

Relan ★★★★★
()
Ответ на: комментарий от Relan

> Что мешает сделать несколько планировщиков ?

>>Переключаться между ними в run time нельзя -- только пересобирать ядро.

Ничего подобного: в сусе достаточно выбрать планировщик в настройках yast-a и перезагрузить компьютер.

GladAlex ★★★★★
()
Ответ на: комментарий от Boy_from_Jungle

>Чем BFQ не устраивает?!

BFQ основан на CFQ и его полезность только в лучшей пропускной способности работы с винтами. На отзывчивость системы он никакого действия не оказывает.

Robotron
()
Ответ на: комментарий от GladAlex

> Ничего подобного: в сусе достаточно выбрать планировщик в настройках yast-a и перезагрузить компьютер.

А можно скриншот? Просто кроме CFS в ядре AFAIK больше никакого планировщика на данный момент нет =).

Deleted
()
Ответ на: комментарий от Turbid

> Выше же кто-то писал что в ядре специальный фреймворк для планировщиков.

В дереве исходников давно спокойно сосуществуют несколько планировщиков. Вроде Коливас когда-то предлагал фреймворк для их переключения в run time, но его не приняли.

Relan ★★★★★
()
Ответ на: комментарий от eugene2k

> А ядро там ведь не во всех системах совершенно разное. Сервер, десктоп, и, вероятно кластер работают скорее всего на одном ядре. Мобайл работает на другом ядре, но мсовцы ее сейчас собираются пристрелить и следующая мобайл вроде будет на стандартном ядре.

ЕМНИП сейчас вендоядра три: сервер/десктоп, мобайл и кластер. А мобайл-ядро ИМХО они убирают только потому, что мобильные устройства доросли по мощности до запуска обычной венды =).

Deleted
()
Ответ на: комментарий от Correctnoe_imya_polzovatelya

В профиле у него написано "Последний логин: 15.08.2008 14:56:07". Подозреваю что кто-то опять раскочегарил машину времени.

Deleted
()
Ответ на: комментарий от Boy_from_Jungle

>> На отзывчивость системы он никакого действия не оказывает.

>С чего ты взял?!

С этого - "BFQ is a proportional share disk scheduling algorithm, based on CFQ, that supports hierarchical scheduling using a cgroups interface."

http://feanor.sssup.it/~fabio/linux/bfq/

Robotron
()
Ответ на: комментарий от isden

>оппа. а это где так настраивается?
man schedtool

А то что Коливас сделал, я так понимаю вот тут выставляется.
% cat /sys/block/*/queue/scheduler
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]

anotheranonymous
()
Ответ на: комментарий от anonymous

Ух ты, анонимусов запилили?

anonymous
()
Ответ на: комментарий от Deleted

>> Ничего подобного: в сусе достаточно выбрать планировщик в настройках yast-a и перезагрузить компьютер.

>А можно скриншот? Просто кроме CFS в ядре AFAIK больше никакого планировщика на данный момент нет =).


http://www.dedoimedo.com/images/computers/2008/suse-11-kernel-settings.jpg
http://www.susegeek.com/wp-content/uploads/2008/09/sysrq2.png

GladAlex ★★★★★
()

выбор планировщика

Раз уж тут собрались специалисты по планировщикам...
Zenwalk тормозит на дисковых операциях, планировщик cfq. Какой лучше использовать и где его выбрать или настроить?

Satou ★★★★
()

В этой теме кто-то массово мешает в одну кучу CFQ, CFS, BFQ и BFS.

Deleted
()
Ответ на: комментарий от Fragster

>> А можно скриншот? Просто кроме CFS в ядре AFAIK больше никакого планировщика на данный момент нет =).

>http://imagebin.ca/view/3_JrlL3Q.html


Это совсем не то!!! Это планировщик ввода-вывода!!! Его можно даже без
перезагрузки поменять для каждого блочного устройства через /proc или /sys (не могу сейчас посмотреть)

ttnl ★★★★★
()
Ответ на: комментарий от anotheranonymous

>А то что Коливас сделал, я так понимаю вот тут выставляется.
>% cat /sys/block/*/queue/scheduler

>noop anticipatory deadline [cfq]

>noop anticipatory deadline [cfq]

>noop anticipatory deadline [cfq]


Ты разницу между вводом-выводом и процессами понимаешь?

Процессы - это то, что ты видишь по команде ps, а также потоки.

Кстати, планировщик I/O можно поменять таким макаром:
echo deadline > /sys/block/hda/queue/scheduler

ttnl ★★★★★
()
Ответ на: комментарий от Deleted

>Я хотел скачать, что предпочёл бы на всех девайсах одно и то же ядро, собираемое из одних и тех же универсальных исходников, но с разным конфигом сборки или настройками, применяемыми во время загрузки системы. Как-то так.

Вспомним с чего все началось. Ты пожаловался что СК недальновиден ибо его серверы не волнуют. Ну дык ничто не мешает включить его планировщик в основную ветку и использовать только для сборки ядер для десктопных дистрибутивов. Конфигом или настройками.

То что сейчас это патч временное явление, если его начнут использовать дистрибутивы, то Линус скорей всего включит его в основную ветку. Прошлый патч умер собственно поскольку никому не был нужен.

TyhDyh
()

Для тех, кто не в курсе (а таких тут судя по всему много).

В Linux есть два вида планировщиков (scheduler):

  • Планировщик ввода-вывода (I/O scheduler). Этот планировщик управляет тем, сколько операций ввода-вывода может сделать конкретный процесс с конкретным устройством (обычно диском). Примеры: deadline, anticipatory, noop, cfq (Completely Fair Queuing), bfq (Budget Fair Queuing, ещё пока не в ядре). Для разных девайсов можно выбрать свой планировщик ввода-вывода, причём сделать это во время работы через /sys.
  • Планировщик процессов (Task scheduler). Этот планировщик управляет тем, сколько процессорного времени на каком процессоре или ядре выделить конкретному процессу. Примеры: cfs (Completely Fair Scheduler, единственный в ядре), bfs (сабж).
Deleted
()

Может попроую сегодня.

anonymous
()

Торвальдс в курсе?..

JN
()
Ответ на: комментарий от TyhDyh

> Вспомним с чего все началось. Ты пожаловался что СК недальновиден ибо его серверы не волнуют. Ну дык ничто не мешает включить его планировщик в основную ветку и использовать только для сборки ядер для десктопных дистрибутивов. Конфигом или настройками.

Так теперь Коливас сам этого не хочет. Почитай первоисточник то =).

Чтобы не было непоняток с моим личным мнением: я не против BFS. Более того, я использовал прошлые патчи Коливаса на десктопе до того, как Молнар написал CFS, Коливас на это обиделся и прекратил разработку. Но я против растущей кучи дистрибутиво-специфичных патчей. Одно другому не мешает. А ешё чуть выше я попытался объяснить, почему прошлый патч Коливаса не приняли в основную ветку ядра.

Deleted
()
Ответ на: комментарий от Relan

>> Что мешает сделать несколько планировщиков ?

>Переключаться между ними в run time нельзя -- только пересобирать ядро.


4.2

madcore ★★★★★
()
Ответ на: комментарий от madcore

Достал этот Коливас, когда у него сайт заработает...

Robotron
()
Ответ на: комментарий от Deleted

>Так теперь Коливас сам этого не хочет.

в тексте новости "скорей всего не появится"(нет прямого указания что он не хочет), а фак с его сайта у мя не грузится =(

>А ешё чуть выше я попытался объяснить, почему прошлый патч Коливаса не приняли в основную ветку ядра.

только потому что в нем сомневались как в ментейнере?

TyhDyh
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.