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

ок, разжую ещё: есть 100 процессов по 0.1% от ядра кто мешает распределить их равномерно по ядрам? правильно! никто! если есть процесс с сильным перекосом в потреблении, то тут нихера не сделать - с этим я, заметь, не спорю. ещё будут глупые вопросы?

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

ок, разжую ещё: есть 100 процессов по 0.1% от ядра кто мешает распределить их равномерно по ядрам?

профита нет. А чтоб равномерно распределить, нужно ещё дополнительные вычисления производить

Энергопотребление мешает.

да на детородном органе я вертел ваше энергосбережение!
оно тут никаким боком!
у меня вообще весь acpi и иже с ним выпелены!

А планировщик о твоем органе знает?

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

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

кто мешает распределить их равномерно по ядрам? правильно! никто!

Ты случайно не анестезиолог?

кто мешает распределить их равномерно по ядрам?

Но зачем? Чтобы коньки красивше выглядели?

Но зачем?

я уже ответил

нет, я, можно сказать, слесарь с ключом на 32

По-моему, выгоднее переключиться на performance.

По-моему, выгоднее переключиться на performance.

Если пользователь сказал ядру: «ondemand», надо оставаться в рамках ondemand. Но если при этом работу можно сделать быстрее, затратив при этом меньше энергии, почему не делать так?

нет, я, можно сказать, слесарь с ключом на 32

Не распарсил.

Не распарсил.

парси

Я так и не понял зачем тебе это. И какой конкретно профит в конкретных попугаях ты хочешь получить?

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

Так что все пихать на одно ядро вполне логично. Да и задачи об оптимальном заполнении обычно так и решаются (а потом начинают перекладывать из одного места в другое, но только после того, как начинается нехватка ресурсов).

Я так и не понял зачем тебе это.

***... я уже ответил

tl;dr: мегабакс хочет выровнять нагрузку просто ради выравнивания. Если вы считаете, что это бессмысленно, помолчите, малыши. Что непонятно?!

Ну пусть пишет патч к ядру. Других путей нет.

multiprocessor scheduling is an NP-hard optimization problem.

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

Написать свой костыль на баше?

PS а зачем это нужно? Сходу в треде ответа не нашёл.

При избытке задач это одно и тоже.

При избытке задач это одно и тоже.

Нет, посмотри complexity у cfs. Наоборот, там сложность очень простая, как и самая идея в основе.

PS а зачем это нужно? Сходу в треде ответа не нашёл.

just for fun
универсальный ответ

PS а зачем это нужно? Сходу в треде ответа не нашёл.

cpu, нагрузка, равноправие (комментарий)

Написать свой костыль на баше?

ты какой-то не оригинальный
cpu, нагрузка, равноправие (комментарий)

Недопонял. Там же другая задача?

Максимально загрузить ядра -> максимальное кол-во вычислений в сек -> быстрее всего выполнится очередь задач (ну может за исключением маленького хвоста фиксированной длины).

Ну пусть пишет патч к ядру. Других путей нет.

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

Ответ кроется всего-то в отсутствии хорошего высшего образования в области CS + непонимании работы мультипроцессорной системы.

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

Максимально загрузить ядра -> максимальное кол-во вычислений в сек -> быстрее всего выполнится очередь задач

Да, всё верно. Но это не NP-hard проблема. Пусть у нас M процессоров и N тасков (N>M). Из N тасков делаем «кольцо» и через равные промежутки времени (scheduling granularity) берём сегменты этого кольца в M тасков. По-моему, тут не гарантируется честное разделение ресурсов, но гарантируется полная загрузка системы.

А зачем перекидывать какой-то из этих 8-ми процессов на другие ядра, если одно ядро прекрасно справляется с задачей с большим запасом (90% свободно)? Какой в этом вообще смысл?

по-моему это задача планировщика

Задача планировщика решать актуальные проблемы. Пока что проблема не была озвучена, почему планировщик должен это уметь?

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

Так речь же идёт о средней загрузке ядер. Конечно, ядро не может быть загружено, скажем, на 30%. Оно или загружено или свободно. Но в среднем можно посчитать сколько за промежуток времени ядро простаивало. И на основании этого в следующем промежутке времени перераспределить таски.

Тут пролучается бесконечное кол-во работы. Это другая задача.

есть 100 процессов по 0.1% от ядра
кто мешает распределить их равномерно по ядрам?

отсутствие в этом надобности

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

just for fun - это ответ? ну так напиши свой планироващик. just for fun.

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

Кстати, если речь зашла о affinity, то вроде это тоже hint и планировщик не будет страдать упорином пытаясь гарантировано форсить выполнения на указанных ядрам.

Так речь же идёт о средней загрузке ядер.

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

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

Тут пролучается бесконечное кол-во работы

Почему бесконечное? Мы просто его не знаем. Завершившиеся таски выкидываем из очереди. Оно не бесконечное, оно недетерминированное.

В реальности оно «бесконечное» (пока комп работает). Причём, всё гораздо интереснее — есть интерактивные таски, есть те которые жрут весь проц, есть те что спят, есть rt-таски, есть приоритеты...

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

Я об этом и говорю.

в результате все работает в три раза медленнее.

Конечно, поэтому планировщик периодически делает ребалансировку тасков на основе их поведения в прошлом.

Планировщик распределяет задачи оптимально с его точки зрения.

но криво

Ты уверен что это необходимо?

да

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

не распарсил

Кстати, если речь зашла о affinity, то вроде это тоже hint и планировщик не будет страдать упорином пытаясь гарантировано форсить выполнения на указанных ядрам.

костыль

на баше? не вопрос
си - не моё...хотя...

На пальцах, гипотетический пример: запущено 4 процесса, каждый грузит по 23% от одного ядра. Распределяем по всем четырём, ТС доволен, у него красивые циферки в коньках (зачем это ещё надо, непонятно). Но потом мегабакс запускает 1 экземпляр xz, которому надо 100% одного ядра. Он запускается на одном из ядер и получает лишь 67%, работает медленнее, планировщик начинает перекидывать процесс с этого ядра (чтобы xz больше досталось), на само перекидывание тоже тратятся ресурсы (всё это время архивация, естественно идёт медленнее), а итоге получаем 100% на одном, 46% на другом и по 23% на остальных. Потом xz завершается, и планировщику (чтобы у мегабакса были красивые циферки в коньках) надо снова перекинуть с того ядра, где два процесса на свободное. Внимание вопрос: кому и зачем это надо, если никакого профита нет (ни по производительности ни по энергосбережению ни просто по здравому смыслу) нет.

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

это и не требуется, кури задачу

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

перераспределить не осилил!? плохо быть тобой, да

но криво

Чем криво?

да

Можешь обосновать?

не распарсил

Загружать ядра поочередно:

1. эффективнее с точки зрения перформанса

2. эффективнее с точки зрения энергопотребления

3. проще с точки зрения реализации

теперь назови, пожалуйста, критерии, по которым выигрывает твой «равномерный» способ.

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

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

Изначально я говорил о наиболее быстром выполнении всех задач (конечного, заранее известного множества). Эта цель понятна и для ее достижения наращивают гигагерцы, кол-во ядер, кол-во процессоров на плате и т.д.

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

перераспределить не осилил!?

А зачем прераспределять если можно просто грузить ядра поочередно? К чему лишняя работа и падение эффективности?

Видишь, в чем дело, если бы твой способ распределения нагрузки не был бы хуже существующего - то just for funело бы смысл. А так - никто не будет жертвовать производительностью ради какого-то абстрактного «фана».

выдыхай, ты просто не вкурил задачи

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

Внимание вопрос: кому и зачем это надо, если никакого профита нет (ни по производительности ни по энергосбережению ни просто по здравому смыслу) нет.

Более того, есть проигрыш (и по производительности и по энергопотреблению)

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

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

да и на вопрос не ответил - с какого такого всегда страдает первое ядро!?

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