Нагрузка процессора до заданного уровня

Приветствую, уважаемые форумчане!
Встала тут передо мной одна специфичная (хотя, возможно, не такая уж и специфичная) задачка. Необходимо нагрузить ЦП до определённого уровня. При этом система должна работать в штатном режиме, т.е. где-то в фоне крутятся какие-то демоны, работают пользовательские приложения, и при всём этом разрабатываемая утилита должна "добить" уже нагруженный процессор до определённого (скажем, в процентах) уровня.
Всё, что пока что пришло мне в голову: есть бесконечный цикл, внутри которого крутится ещё один цикл, в котором выполняется некая простая и бесполезная арифметика (сложения-умножения-деления целых и действительных чисел). После выполнения внутреннего цикла стоит задержка. Варьируя два параметра - количество итераций внутреннего цикла и величину задержки - я могу поддерживать нагрузку на нужном мне уровне. Главная задача, которая встаёт, если мы примем описанную реализацию - подбор указанных параметров на очередном кванте. Ведь в системе уже выполняются какие-то задачи, следовательно, какая-то нагрузка на процессор уже имеется, и надо вычислить такие значения параметров, чтобы суммарная нагрузка равнялась заданной.
Тут мне в голову приходят два варианта: либо побрутфорсить параметры и посмотреть, наблюдается ли какая-то простая зависимость (то, что зависимость нелинейная, я уже выяснил), либо собирать статистику и пытаться экстраполировать функцию двух переменных (от количества итераций и величины задержки). К сожалению, экстраполяция может быть дорогой операцией в данном случае и вносить дополнительные погрешности в статистику нагрузки (получается замкнутый круг).
Кто что думает по поводу описанного алгоритма? Возможно, кто-то сталкивался с подобной задачей и решил её иначе? Или кому-то на ум приходит эвристика для подбора указанных параметров? Или в алгоритме есть изъян и он не приведёт к желаемому результату?
Всем заранее спасибо.

P.S. Знаю, многабукав, но ничего с собой поделать не могу

0

А просто время nanosleep() регулировать? Получится "кусками" времени жарим до 100%, потом отдыхаем.
Ну это как аналогия из ШИМ, правда как мониторить-то? Надо узнавать кол-во процев=>создавать соответствующее кол-во форков, текущую среднюю нагрузку по всем процессорам/по каждому в отдельности и т.д. Логика управления будет не из лёгких.

0

drfaust, собственно говоря, я ведь именно такую идею и описал:

Сообщение от silent_1991 цикл, в котором выполняется некая простая и бесполезная арифметика

Это мы как раз жарим до 100%.

Сообщение от silent_1991 После выполнения внутреннего цикла стоит задержка

Это отдых.

Сообщение от drfaust Логика управления будет не из лёгких.

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

Сообщение от drfaust Надо узнавать кол-во процев=>создавать соответствующее кол-во форков, текущую среднюю нагрузку по всем процессорам/по каждому в отдельности и т.д.

Тут я могу ограничиться одним многоядерным процессором. Узнать количество ядер, запустить соответствующее количество тредов, выставить им affinity проблем нет. Кроме того, достаточно уметь поддерживать нужный уровень нагрузки в одной треде. Тогда, если каждая треда будет уметь регулировать уровень нагрузки на своё ядро, то, например, 4 треды, каждая из которых грузит своё ядро на 60%, будут грузить на 60% четырёхядерный процессор. Если в системе несколько процессоров, достаточно запустить нужное количество копий утилиты и выставить им всем affinity (например, taskset'ом).
Короче говоря, задача прекрасно поддаётся декомпозиции. По сути, мне надо уметь в одной треде регулировать нагрузку на ядро, на котором она крутится. А дальше запустить нужное количество тред - дело техники. Все они будут работать независимо.

0

Не претендую на ответ, просто для информации. Я когда-то читал, что всякие утилиты для всяких тестов процессоров работают путем его нагрузки SSE-инструкциями умножая матрицы. Может вам в эту сторону посмотреть. Но там в моем понимании ассемблер, а не Си...

0

Сообщение от HighPredator всякие утилиты для всяких тестов процессоров работают путем его нагрузки SSE-инструкциями умножая матрицы. Может вам в эту сторону посмотреть.

Проблема в том, что если бы мне нужна была такая нагрузка, которую предлагают эти утилиты, т.е. нагрузка ЦП на 100%, я бы просто собрал одну из них под нужную платформу и отправил задачу в резолв.

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

0

Сообщение от silent_1991 Тут я могу ограничиться одним многоядерным процессором. Узнать количество ядер, запустить соответствующее количество тредов, выставить им affinity проблем нет. Кроме того, достаточно уметь поддерживать нужный уровень нагрузки в одной треде. Тогда, если каждая треда будет уметь регулировать уровень нагрузки на своё ядро, то, например, 4 треды, каждая из которых грузит своё ядро на 60%, будут грузить на 60% четырёхядерный процессор. Если в системе несколько процессоров, достаточно запустить нужное количество копий утилиты и выставить им всем affinity (например, taskset'ом). Короче говоря, задача прекрасно поддаётся декомпозиции. По сути, мне надо уметь в одной треде регулировать нагрузку на ядро, на котором она крутится. А дальше запустить нужное количество тред - дело техники. Все они будут работать независимо.

Ну да, клепаем нужное кол-во потоков (кол-во процев*кол-во ядер в общем случае) с привязкой к конкретному процу/ядру, и отдельным потоком регулируем время sleep`а или другого засыпания на всех "нагрузочных потоках".

Только вот как вычислить соотношение нагрузка/время_сна, и как быть с энергосбережением=троттлинг/буст - по идее изменение частоты проца должно изменять это самое соотношение нагрузка/сон? Время сна опять же должно быть достаточно большим, а значит и цикл должен быть достаточно долгим, иначе начнёт сказываться работа планировщика ядра.

Матрицы в цикле можно применять, но только маленькие и использовать int/float. Цикл нагрузки(в случае больших матриц) не должен скидывать кэш - сильно скажется на производительности системы.

1

Сообщение от drfaust Матрицы в цикле можно применять, но только маленькие и использовать int/float. Цикл нагрузки(в случае больших матриц) не должен скидывать кэш - сильно скажется на производительности системы.

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

Сообщение от drfaust Только вот как вычислить соотношение нагрузка/время_сна

Да, вот именно - как это делать? Либо нужна какая-то эмпирика, либо придётся экстраполяцию на основе статистики проводить, соответственно, будет некий бутстрап, пока система не выйдет в рабочий режим (пока не накопится достаточно статистики, чтобы результаты экстраполяции были приближены к реальности).

Сообщение от drfaust и как быть с энергосбережением=троттлинг/буст - по идее изменение частоты проца должно изменять это самое соотношение нагрузка/сон?

Думаю, эта проблема отпадёт, как только я научусь динамически менять значение параметров. Загрузка процессора - величина объективная, и главное, какая она на данном кванте, а не какая у неё динамика с момента старта. Уменьшилась частота -> возросла нагрузка -> запустили алгоритм коррекции параметров -> загрузка пришла к требуемому уровню. И так каждый квант.

0