cpu, нагрузка, равноправие

что да, строго говоря, решение не оптимально, но для реальных задач его более чем достаточно?

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

В принципе, там есть ещё что улучшать. Например, я сейчас пытаюсь учесть взаимное влияние задач друг на друга.

Почему сразу бухой, может он на станции восток живет или же счетчик пропатчил.

И cgroups пихать на выбранный процессор и блокировать его для всех остальных?

Да, так можно. Правда, есть нити ядра которые игнорируют affinity (управление cgroups в release notify agent)

Посмотри вот это: https://www.kernel.org/doc/Documentation/cgroups/cpusets.txt

http://s01.yapfiles.ru/files/491313/gifki227302.gif

Правда, есть нити ядра которые игнорируют affinity

Это плохо.

Спасибо, уже смотрю.

Ванильная. Я тоже тред не читал. Я попытался развеять некоторые мифы по поводу планировщиков.

а, ясно.

Кстати, пока писал понял зачем нужны красно-чёрные деревья в cfs — чтобы быстрее находить таски которые давно не выполнялись. А красно-чёрное потому что оно (автобалансировка) занимает относительно мало времени по сравнению с остальными видами деревьев.

да, красно чёрное дерево отличается самой быстрой вставкой и самой плохой балансировкой. Длинна самой плохой ветки вдвое больше самой хорошей. Т.е. это «плохосбалонсированное» дерево. Но там хорошести и не надо, ибо задач совсем немного. А вот за то требование к вставке очень жёсткие по времени. «Сбалансированное дерево» хорошо, когда редко вставляешь, но очень часто ищешь(там «хорошая» ветка всего на два узла короче «плохой». А не вдвое).

Ну больше никому в голову это не приходило, никому не нужны красивые цифры в коньках. Если тебе нужны, можешь написать свой планировщик just for fun.

может, легче подделать выхлоп коньков и htop?:)

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

А, теперь все понятно.

ничего тебе не понятно, увы

Чел пришел и хочет чтобы было как он хочет. Но больше никому это не надо, а для всех еще и очевидно что это во вред. Но ТС это не понимает.

И все просит и просит, показать ему как делать не нужно, попутно называя всех дибилами и идиотами.

</thread>

брысь под лавку!

Как только процесс завершает выполнение или засыпает управление передаётся планировщику который может выравнить загрузку. Так что в том смысле что ты говоришь выровнить нагрузку можно.

Ну конечно можно - если перекидывать процессы между ядрами сотни раз в секунду. Я об этом сразу сказал.

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

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

А это не настолько большая проблема как кажется. Между соседними (sibling) ядрами так вообще даром. Я уже говорил про kernel.sched_migration_cost_ns ?

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

BTW. На винде процессы более-менее равномерно размазываются по ядрам (турбо-режима нет).

будучи реализована просадит производительность

обоснуй

Обоснуй обратное

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

понятно всё с тобой

Ну вроде бы весь тред тебе доказывает что ты лох. Пора задуматься

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

я вот сейчас вспомнил тред про ограничение кеша торрентам.
и что же там было? правильно - я дебил и производительность просядет.
а на деле вышло как я и сказал - нужный системе кеш остался на месте, потому производительность по сравнению с дефолтным раскладом только повысилась!
но куда этим доказунам - они увидели «ограничить кеш», а что за кеш и что за ограничение их мозг осилить не смог.

А ведь и правда — сколько раз, а?

Да, отличный технически обоснованный аргумент — ты считаешь себя правой стороной в не связанном никоим образом с предметом разговора споре, что и доказывает твою многогранную развитость — как ты можешь быть не прав в предмете этого спора?

да и при неполной нагрузке ядер никакого проседания не будет

А при полной - будет.