Кон Коливас (Con Kolivas), автор планировщика задач BFS (Brain Fuck Scheduler), ориентированного на обеспечение оптимальной отзывчивости приложений на рабочем столе, представил (https://lkml.org/lkml/2016/10/29/4) первый публичный выпуск нового планировщика MuQSS (Multiple Queue Skiplist Scheduler), который позиционируется как следующий шаг в развитии BFS, адаптированный для современных реалий. MuQSS может выступать в качестве прозрачной замены BFS и также нацелен на повышение отзывчивости и интерактивности обычных пользовательских задач.
MuQSS изначально ориентирован на обработку заданий в нескольких очередях и устраняет ограничения BFS, связанные с масштабируемостью на многоядерных системах. В MuQSS продолжено использование алгоритмов и упрощённой архитектуры BFS, которые переработаны для масштабирования на оборудовании с любым числом процессорных ядер и систем с любым числом активных процессов. Если в BFS использовалась единая очередь ожидающих выполнения заданий, то в MuQSS применена схема с раздельными очередями для каждого ядра CPU, что позволило добиться более равномерного распределения нагрузки по ядрам CPU и избавиться от блокировок, охватывающих сразу все ядра CPU.
При этом удалось обойтись без сложных схем балансировки заданий между очередями, благодаря задействованию не требующего установки блокировок метода опроса очередей и применению списков с пропусками (https://ru.wikipedia.org/wiki/%D0%A1%D0%... вместо ранее используемых связанных списков (https://ru.wikipedia.org/wiki/%D0%A1%D0%.... В процессе обработки очереди MuQSS оценивает наличие в других очередях заданий с истекающим deadline и на лету принимает решение о выполнении, если это требуется для минимизации задержек или балансировки нагрузки на CPU.MuQSS не претендует на роль полнофункциональной замены основного планировщика ядра Linux, ориентируясь только только на работу при выполнении специфичных для настольных систем задач. Например, не MuQSS отягощён поддержкой cgroups, справедливого распределения приоритетов и точного учёта крайнего расчётного времени (deadline), но демонстрирует (http://ck-hack.blogspot.ru/2016/10/interbench-benchmarks-for... более высокую отзывчивость в тестах, оценивающих работу в интерактивных приложениях, при параллельном выполнении в системе ресурсоёмких задач, таких как компиляция кода, обработка видео или распаковка архивов.
URL: https://lkml.org/lkml/2016/10/29/4
Новость: http://www.opennet.dev/opennews/art.shtml?num=45395
Не использовал патчи -ck для < 2.6.22 так как ещё не умел, но был о них очень наслышан. К моменту, когда перешёл на Gentoo, вышел BFS. Установил - и YouTube стал идти плавнее. BFS - нужен! Если у вас меньше 16-ти физический ядер, то нужен однозначно!MuQSS? Щас затестю :-) Говорят, CFS с тех времён подтянули до уровня BFS (конкуренция, фигле), что ж глянем на предмет революции в планировщиках :-) На производительность не жалуюсь правда - в тот раз был Pentium IV, тихий ужос скажу я вам. Я слишком поздно узнал, что всю первую половину 00-х AMD был лучше.
А ты сейчас BFS используешь? Просто если суддить по тексту новости, то профит есть только на Атомах, Athlon Neo и прочих одноядерных компах. Не сводится ли всё на нет при 2+ ядрах?
На самом деле, на одноядерниках как раз и нет профита от BSF, наоборот только хуже становится. При запуске почти любого приложений система подвисает на 1-2 секунды (мышь становится неуправляемой), на CFQ такого не наблюдается. Это из личного опыта.
*BFQ
Только речь о планировщиках задач, а не I/O.
> Только речь о планировщиках задач, а не I/O.Ты ему только не говори что еще и планировщики сети бывают, а то он сойдет с ума :)
"YouTube стал идти плавнее" - после такого, можно вообще не читать ваше сообщение.
Что такого? Новомодными VDPAU я к этому моменту не обладал
> Что такого?То самое: метрика из разряда "волосы стали на 20% шелковистее". Простите, а в каких единицах измеряется шелковистость волос и плавность ютуба?
> Простите, а в каких единицах измеряется шелковистость волос и плавность ютуба?Вы для начала определили бы, в каких единицах измеряется пригодность сообщения к прочтению, а то как-то демагогией отдаёт за версту.
PS: по существу: видимо, "на глазок" -- или есть заметные дёрганья, или нет/редко.
Человеку правильно все сказали, наверное намекая что "на глазок" - не является хорошим инструментом. К тому же в силу склонности двуногих к эффекту плацебо ютуб может стать плавнее, а волосы шелковистее даже если в коде ничего не менять и дать пожевать прессованый мел. Поэтому таким заявлениям грош цена без инструментированных метрик, да и запустить latencytop до выдачи громких заявлений - не очень сложная наука.
при всем уважении, речь не об эффекте плацебо, а о самообмане
эффект плацебо имеет эффект, а самообман — нет
Как попробовавший сабж в составе Liquorix, могу сказать, что разница действительно видна, причем вне зависимости от VDPAU и вообще не только при просмотре видео. Например, при всех ядрах загруженных кодированием x265 прокрутка в Firefox остается почти такой же плавной, как при свободном CPU. Анимации KDE тоже более плавные. Я хз в каких единицах измеряется плавность, но эффект есть, это факт. (Core i7 2600K. Железо и софт в ходе экспериментов не менялись, только ядро).
Дёрганья на ютубе -это или протухший комп или замечательный свободный видеодрайвер (нуво как раз вот такой) или оба два сразу. Это к бабке не ходить! И на планировщик тут вообще нечего кивать.
В чём измеряется шелковистость волос не знаю. А вот плавность можно измерять в FPS.
Больше нет слова Fuck в названии? Можно надеяться на включение в ядро :-)
Без поддержки cgroups? Ха ха
> Без поддержки cgroups? Ха хаДа, это само по себе хорошо характеризует автора в наши дни :o)
> Да, это само по себе хорошо характеризует автора в наши дни :o)Ну тогда ваш любимый openvz - просто кошмарище, потому что без такого управления ресурсами он вообще будет ни о чем.
openvz сам по себе кошмар, что с управлением ресурсами, что без.
Особенно сейчас с их идиотской манерой разработки, одни патчи есть в этой ветке.. другие патчи только в этой..
и конфигурируй как хочешь..
> openvz сам по себе кошмар, что с управлением ресурсами, что без.Спору нет, просто без управления ресурсами в духе того что сейчас cgroups обеспечивают - их продукт вообще не взлетел бы и мы бы его вообще не обсуждали.
> Особенно сейчас с их идиотской манерой разработки, одни патчи есть в этой
> ветке.. другие патчи только в этой..
> и конфигурируй как хочешь..Я уже сконфигурировал все что мне было надо без них. Не нравится мне когда системное администрирование превращают в порнографию, поэтому я как-нибудь обойдусь без этой чудной компании с чудными продуктами. Пусть они там как-нибудь сами пользуются своими дистрибутивами и черти-какими ядрами.
Пишите сюда кто использует Brain Fuck Scheduler и почему ? )
Весause we like to fuck brains.
> Пишите сюда кто использует Brain Fuck Scheduler и почему ? )Потому что кто-то любит плацебо? Или "увеличение" производительности в несколько сотых процента?
плацебо — пустышка, которая приводит к положительному эффекту, а не то, что Вы подумали
Я юзал издавна и юзаю уже по привычке. Пробовал на атлоне двухъядерном, тема крутейшая. как раз на нём и видишь, что youtube работает "плавнее". А если быть точным, то фулл хд работал на фулскрине хорошо и не проседал фпс, хотя комп был довольно скромный. Меньше лагов и лучше производительность
Измерять производительность по тытрубе -- верх идиотизма. Вот когда предоставишь результаты тестирования, например, компилирования в несколько потоков с MuQSS и без, тогда поговорим. Я пока разницы не заметил, железо не самое мощное. Кстати говоря, по моему даже 3.16 работает, субъективно, побыстрее. Проверить пока времени не было.
> Измерять производительность по тытрубе -- верх идиотизма. Вот когда предоставишь результаты
> тестирования, например, компилирования в несколько потоков с MuQSS и без, тогда
> поговорим. Я пока разницы не заметил, железо не самое мощное. Кстати
> говоря, по моему даже 3.16 работает, субъективно, побыстрее. Проверить пока времени
> не было.а как можно увеличить производительность одного и того же железа? фпс не проседал просто потому, что приоритет отдавался больший этому процессу, планировщик распоряжался ресурсами в соответствии с потребностями десктопа. Хочешь тесты и диаграмки -- проведи их сам. С компилированием вообще насмешил, конечно, прирост может быть, но с одним и тем же компилятором и винтом ты вряд ли увидишь разницу больше пары процентов
Я просто пример реальной задачи, которой реально нужно распределение ресурсов привёл. Твоему ютьюбу точно это не поможет, там уж скорее от браузера зависит. И потом от разных планировщиков получаешь некий гипотетический прирост, когда есть несколько распределённых процессов. Особенно это видно на многоядерных процессорах, когда например 4 процесса распределяются по ядрам, а не висят все на одном, безбожно при этом тормозя.
Вы не можете понять прочитанное в новости. Планировщик заточен под десктопные задачи. Компилирование чего либо сложно отнести к таковым. Достигаемые цели лежат в разных плоскостях.
А вот ютюб вполне себе типичен для десктопа. И никакое "там уж скорее от браузера зависит" в данном случае тут не причем. Просто планировщик должен каким-то образом равномернее загружать ядра. Если при этом на глаз заметно, что ютюб стал работать без рывков, то эффективность планировщика на лицо. Разумеется, что, если процессор априори слаб для воспроизведения видео, то тут никакой планировщик не поможет.
Раньше использовал, месяца 4. Визуально не заметил ускорения. Проводил бенчмаркинг игры ради которой заморачивался с ним - оказалось стало хуже. Может не то что-то накрутил, хз. Слишком тонкие для меня материи.
Опять радикально починили 12309?
Смысл не понимай, хрень понаписай. 12309 связан с I/O элеваторами, а не процессорными.
не факт
> не фактВообще-то факт: для процессорного планировщика чисто технически сложно вклинить систему настолько что гораздо более медленный двуногий вообще заметит лаги.
Особенно в 1000 Hz ядрах, где kernel preemption разрешен. Если уж кого латенси парит, вот эту сладкую парочку стоит первым делом проверить. Ну как, если кернел пойдет запрос обрабатывать и встрянет на пару секунд при этом - весь мир таки подождет. Или по крайней мере ощутимая его часть. А если кернел сам себя preempt'нет и продолжит туповэйтинг или что там у него когда-нибудь потом - остальным ждать не придется.
Не связан он с I/O элеваторами. С page cache и vm вообще связан.
Уверен? Может ты ещё и разработчик ядра? Никто это починить не может уже много лет, а ты так вот говоришь, как будто точно знаешь. А если знаешь, почему разрабам не сказал или сам патч не написал? Все бы тебе благодарны были только.
> Уверен? Может ты ещё и разработчик ядра?Вообще он все правильно написал. Оригинальный 12309 был связан с тем как работает выделение памяти в линухе. Ядро могло отрастить большой дисковый буфер над медленным накопителем. Дальше как известно ядро при нужде выделить память может этот буфер урезать. И вот просит какая-то программа память. Ядро пытается урезать буфер и начинает его скидывать на накопитель, чтобы потом отобрать эту память. А там возьми и окажись флешка со скоростью записи мег в секунду или ноутбучный хард какой. И программы начинают взвисать на запросах выделить им память, пока ядро выжимет по каплям дисковый буфер на медленный накопитель.
> Никто это починить не может уже много лет, а ты так вот говоришь, как будто точно знаешь.
Я точно знаю: 12309 починили несколько лет назад. Пруфлинк надо?
> А если знаешь, почему разрабам не сказал или сам патч не написал? Все бы тебе благодарны были только.
Именно 12309 был починен несколько лет назад. И не надо валить разные баги в один баг в багтрекере, это некультурно.
> Именно 12309 был починен несколько лет назад.Якобы. А у меня и ещё одного человека, которого я лично знаю, он продолжает проявляться.
> Якобы. А у меня и ещё одного человека, которого я лично знаю,
> он продолжает проявляться.Может быть, стоит прекратить ламерствовать и осознать что одинаковые проявления "система тормозит" могут скрывать в себя бесконечное множество самых разных багов? И это не является 12309. Это какой-то другой баг с похожими проявлениями.
И таки да, если вы не будете писать баги или будете оформлять их как бакланы, с описанием "система тормозит" - никто их не починит. Потому что никто не узнает. А если и узнает то не сможет воспроизвести у себя. Ну и говоря за себя - почему-то линуксные разработчики зашибли довольно много багов которые повесил им я. Но я мог описать проблему и знал кого из разработчиков пнуть, чтобы все заверте...
Система тормозит, только когда начинает писать в своп. Причём не важно, будет это ZRAM или своп на диске. Об этом баге известно многим, и лишь у немногих он не проявляется. Видимо они никогда не забивают память полностью. Никакие твики ядра не помогают, пробовали уже, да и костыль это. Этот баг то исправляют, то он опять выползает откуда-то, о чём тут говорить то?
>> Именно 12309 был починен несколько лет назад.
> Якобы. А у меня и ещё одного человека, которого я лично знаю,
> он продолжает проявляться.Ты и твой одноклассник - лузеры.
Ну так потюнь vm.dirty_background_ratio / vm.dirty_ratio, чтобы минимизировать вероятность возникновения ситуаций, когда сброс страничного кэша становится синхронным. А лучше купи себе побольше памяти.
> А лучше купи себе побольше памяти.Ну конечно, купила-притупила. Чтобы купить побольше памяти, мне понадобится купить новую мать. Но я чувствую, такими темпами мне и 16 гигов не будет хватать.
Одна память не поможет. У меня 16 Гб (и своп на SSD - используется крайне редко, даже если используется, не тормозит), но система встает колом, если надо записать пару гигабайт на флешку. Даже на быструю флешку по USB 3.0. Как только начинают сбрасываться грязные страницы, все остальное начинает жутко лагать. Вот эта проблема: https://lwn.net/Articles/572911/
Для Андроида старались?
пробовал BFS на ранних стадиях его разработки - устраивал вполне.
потом начали химичить - стало совсем плохо со стабильностью, потом стали частыми фризы.
положение дел не изменялось от версии к версии.
потом попробовал MuQSS - все еще хуже - уж слишком оно сырое и бажное.
на 4.8.5 вполне теперь нормально работает дефолтный планировщик (касаемо интерактивности при большой нагрузке), правда на самосборном ядре.
У меня и BFS и MuQSS работают нормально начиная с 4.х ядра. Но и улучшений я не вижу. Видимо это варьируется от железа к железу.
А, для SSD только NOOP годится сегодня? Или есть другие планировщики для десктопа с учётом особенностей SSD?
> для SSD только NOOPНе тестировал, но наверное есть смысл заморочиться с тонким тюнингом CFQ. По идее там надо сотни миллисекунд превратить в единицы/десятки миллисекунд. В теории должно выходить лучше, чем "очередь команд не более 31 операции" на уровне SATA+noop/blk-mq.
Пресловутый похороникс недавно как раз тестировал. И там получилось достаточно разнобойно. В одних тестах лучше одно. В других другое. А еще эти тесты не меряли латенси. А как известно, latency и bulk performance - две разных стороны медали. А чтобы bulk performance уживался с low latency - это почти философский камень системных архитектур.
ну так то, тащем та deadline для ssd, с чего вы взяли что noop ?
Для SSD есть blk-mq, но это не планировщик, а фактически альтернативный block layer. Планировщик для него вроде бы еще не сделали.
Пропатчил сейчас 4.8.5 новеньким MuQSS. Система реально стала отзывчевее, конкретно: хром стал быстрее запускаться.
Похоже на плацебо/изменение несвязанных параметров, запуск хрома это io-bound задача.
linux-liquorix (4.8-8) unstable; urgency=medium
* merge 4.8.6
+ * merge BFQ v8r5
* remove writeback throttling patches (cfq, bfq, block)
* merge only softirq patches from MuQSS v135
* update version to 6.1