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

Не говорил ты, зачем жертвовать производительностью

правильно, я этого не говорил - ею не надо жертвовать

зачем это может понадобиться

just for fun, ради красивых коньков и т.д. - мало чтоль!? :3

непонятно даже ради чего

мне за первое ядро обидно - что не понятно!?

cpu кеша для команд может хватить и на больший кусок времени

И что?

А почему нет?

а почему да?

надо чтобы страдало второе? или третье?

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

правильно, я этого не говорил - ею не надо жертвовать

Но придётся, я уже привёл пример, в какой ситуации (вполне обычной).

just for fun, ради красивых коньков и т.д. - мало чтоль!? :3

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

правильно, я этого не говорил - ею не надо жертвовать

Но ты предлагаешь это сделать. Схема с равномерной нагрузкой проигрывает в производительности схеме с поочередной загрузкой.

just for fun

Ну и сделай свой планировщик. А люди, которые серьезно этим занимаются, видимо, считают, что just for fun - это не причина делать хуево.

мне за первое ядро обидно - что не понятно!?

Грузится не первое ядро, а наиболее загруженное. А если уж нагрузка одинаково - будет первое, да.

Ничего, просто у процессора до фига информации о том как его будут козлить в ближайшее время. Только вот смысла дополнительно считать «как» — нет. Для специфических задач, нужно делать свой планировщик, ну так вроде в oracle есть такая фича. Для numa, например, было бы вполне логично пихать все задачи относящиеся к обработке одних данных на один процессор, чтобы не кидать из одной области оперативы в другую сотни мегабайт.

нет! надо чтоб страдали одинаково

Зачем надо? кому надо?

а почему да?

Потому что нету никакой разницы. Выбрали первое. Можно было точно так же взять второе. Но первое - логичнее, очевидно.

Но придётся

нет

Ну больше никому в голову это не приходило

4.2

можешь написать свой планировщик just for fun.

обычный обиженный жизнью задрот - так и запишем

Ничего, просто у процессора до фига информации о том как его будут козлить в ближайшее время.

Нет, у него нету такой информации.

Будешь писать — пиши c поддержкой numa. Я бы тоже присоединился. Такой планировщик очень неплохо бы смотрелся для postgresql.

нет

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

обычный обиженный жизнью задрот - так и запишем

Да ты охуел, парниша.

Ну формально, кеш команд находится внутри процессора, так что «знает». Хотя это слово по отношению к куче транзисторов звучит как оксюморон.

4.2

Что 4.2, ебанько? Хочешь сказать, что есть какие-то долбоебы, которые решили джаст фор фан написать планировщик, который будет в сравнении с существующими тормозить и греть ядра, но зато циферки даст ровные, четкие?

Ну всё ясно. Аргументы кончились, пошли в ход бессмысленные «нет», «4.2» и переход на личности. Когда нечего сказать в пользу своей точки зрения, приходится просто громко и много раз её повторять. Мне здесь всё ясно, что-то объяснять бесполезно.

Какой-то прямо день неадекватов сегодня.

Видимо потому, что самый жручий процесс всегда кидается на первое ядро.

надо же! ты хотя бы чуть-чуть углубился в тему - вопрос: КАКОГО ХРЕНА ОН ТАК ДЕЛАЕТ???

ВНЕЗАПНО: что-бы было быстрее. Быстрее не какой-то отдельный процесс, а В ОБЩЕМ. Т.е. если у тебя работает тест, который на 4х ядрах считает попугаи, то всякие браузеры/плееры и прочая ерунда кидается на одно самое горячее ядро. И попугаев получается соответственно больше, ибо трём ядрам считать попугаев никто не мешает, да и первое горячее помогает, в промежутках между ерундой.

Вот и получается, что попугаев больше, и тормозит сильнее :-)

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

Не-не-не, изначально речь шла о том чтобы _расчитать_ за сколько можно выполнить N задач на M процах при условии что известно сколько им нужно ресурсов для завершения.

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

PREEMPT_VOLUNTARY

оно увеличивает «гранулярность» с которой шедулится ядро. С учётом того что ядро обычно жрёт немного лучше крутить sysctl kernel.sched*.

Ну формально, кеш команд находится внутри процессора, так что «знает».

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

Так нету никакого способа предсказать, какая средняя загрузка ядер будет в ближайшие несколько секунд.

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

если есть 8 прог с нагрузкой в 1% от ядра, то что мешает планировщику повесить по 2 процесса на ядро!?

верни стандартный, и он будет вешать как тебе хочется.

Не-не-не, изначально речь шла о том чтобы _расчитать_ за сколько можно выполнить N задач на M процах при условии что известно сколько им нужно ресурсов для завершения.

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

Мне кажется что из второго следует первое, не? А если так, то ты решил NP-трудную задачу. Можешь вставать в очередь за премией.

Но равномерной загрузки ты, глядя на то, что было, не добьешься, очевидно. Т.к. ИРЛ нагрузка процессов постоянно меняется.

Но ты предлагаешь это сделать. Схема с равномерной нагрузкой проигрывает в производительности схеме с поочередной загрузкой.

4.2

на десктопе выигрывает в отзывчивости, а производительность там не нужна. Ну а на серверах обычно так, как ты пишешь.

Процессор берет команды из кеша? Значит кеш и определяет как его будут нагружать в ближайшее время (сколько оно будет — хз, может 1 такт и кеш нужно будет менять, а может и вечный цикл).

Впрочем это разговор ни о чем.

на десктопе выигрывает в отзывчивости

Нет, не выигрывает.

Значит кеш и определяет как его будут нагружать в ближайшее время (сколько оно будет — хз, может 1 такт и кеш нужно будет менять, а может и вечный цикл).

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

А расчитать, когда процессор выйдет за пределы кеша комманд (да и нагрузку по данному кешу в случае если он никогда не выйдет, то есть бесконечный цикл) - алгоритмически неразрешимая задача.

Не-не-не, изначально речь шла о том чтобы _расчитать_ за сколько можно выполнить N задач на M процах при условии что известно сколько им нужно ресурсов для завершения.

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

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

Я не говорил, что всегда определяет, я говорил, что часто определяет.

А расчитать, когда процессор выйдет за пределы кеша комманд (да и нагрузку по данному кешу в случае если он никогда не выйдет, то есть бесконечный цикл) - алгоритмически неразрешимая задача.

Это правда. Я плохо выразился, я сказал «знает», а надо было сказать «есть данные».

на десктопе выигрывает в отзывчивости

Нет, не выигрывает.

«отзывчивость» такая штука, которую сложно измерить объективно. Потом спорить я с тобой не стану. На мой взгляд отзывчивость лучше у ванильного планировщика.

Мне кажется что из второго следует первое, не?

Никак не следует.

Наиболее быстро это ведь «минимальное время»?

Но равномерной загрузки ты, глядя на то, что было, не добьешься, очевидно. Т.к. ИРЛ нагрузка процессов постоянно меняется.

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

Наиболее быстро это ведь «минимальное время»?

Да, но ты его заранее не знаешь. Если только не решить «задачу о многопроцессорных системах».

just for fun, ради красивых коньков и т.д. - мало чтоль!? :3

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

Есть же оценка = сумма времени необходимое для выполнения каждой задачи, это известно заранее. Поэтому, согласно, ствоему утверждению можно наиболее быстро выполнить все задачи (полиномиальное время) и получить точный ответ.

Ты этот момент не желаешь учитывать? Почему?

Я всё по этому поводу написал выше. Естестно я взял простой случай чтобы показать что минимизация простоя cpu hungry задачах делается легко.

И самое сложное это не загрузить ядра, а сделать систему отзывчивой.

Продвинутый планировщик даёт работать старичкам, и гнобит нубов

Как раз наоборот. И этот параметр часто тюнится. Например, у планировщика фряхи это настраивается.

Посему мелкие ненужные задачи пихаются на горячее ядро.

Не надо придумывать, https://www.kernel.org/doc/Documentation/scheduler/* и в комментах ядра и статьях lwn всё расписано на эту тему.

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

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

schedtools

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

А мы решаем другую задачу, она называется jub scheduling. То что ты кинул изначально содержит ограничения на миграции которое и превращает её в NP-hard.

И блокировать ядро для всех остальных процессов. shedtools — хорошая штука, но она для работы с каждым процессом в отдельности, а не для формирования правил «для всех».

сумма времени необходимое для выполнения каждой задачи

на реальных системах в общем случае мы этого не знаем, кстати.

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

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

почему? affinity не означает что ядро блокируется для остальных тасков. Оно означает что таски с affinity mask будут 99% времени шедулится только на этих ядрах. Но не всегда, об этом можно почитать в инете.

Продвинутый планировщик даёт работать старичкам, и гнобит нубов

Как раз наоборот. И этот параметр часто тюнится. Например, у планировщика фряхи это настраивается.

а ты сейчас про какой именно планировщик говоришь? ЕМНИП у мегабакса какой-то не родной, а как раз «продвинутый».

Я всё по этому поводу написал выше.

tl;dr Хоть бы ссылку дал на тот пост, где написал.

Не надо придумывать, https://www.kernel.org/doc/Documentation/scheduler/* и в комментах ядра и статьях lwn всё расписано на эту тему.

это разве не ванильная документация? У меня такой проблемы как у ТСа нет, и загрузка более-менее равномерная. И у меня дефолт.

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

Да, конечно. Но вот величина это субоптимальности мизерная (можно даже тюнить на это планировщик через kernel.sched_migration_cost_ns). Да и гораздо больше потратишь времени на расчёт «оптимального решения».

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

а ты сейчас про какой именно планировщик говоришь?

Я говорю об алгоритмах в общем. Но можно приписать сюда cfs и bfs, я с ними даже немного знаком на уровне сырцов. Интересующимся рекомендую посмотреть bfs. Можно спорить о качестве сырцов, но написано достаточно понятно чтобы вникнуть.

это разве не ванильная документация?

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

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

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

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

Так всё давно сделано — cgroups же. Там почти всё что угодно можно делать.

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

ты бухой, что ли?