Почему диапазон средней нагрузки не 0-1+ для всех процессоров вместе?
хороший (2) syscall меняет относительный приоритет (по сравнению с до этого syscall). Но приоритет установки (2) изменяет абсолютный приоритет .
Так что я понимаю, что приятно (x) (с x очень маленькое число, например, между 0 и 9) является эквивалентом атомарно делать:
// asssume both getpriority & setpriority syscalls are successful
int n = getpriority(PRIO_PROCESS, 0);
n += x;
setpriority(PRIO_PROCESS, 0, n);
Так как несколько процессов могли бы делать то же самое в одном и том же процессе (например, вызов setpriority (PRIO_PROCESS, somepid, n); ....), вам лучше будет использовать атомную операцию, объединяющую их, и это приятно (2)
Но основная причина - наследие и история (и обратная совместимость). IIRC, в 1980-х годах старый Unix (как и SunOS3.2) имел хороший , но не приоритет (но я мог ошибаться).
Вот ваш perl one-liner: он работает с несколькими аргументами файла
perl -i -pe '/^$ARGV,/ or print "$ARGV,"' file1 file2 ...
$ ARGV является магической переменной, которая содержит имя файла текущего файла.
См. http://perldoc.perl.org/perlvar.html#Variables-related-to-filehandles
Разделитель полей (запятая) имеет жесткий код. Вы можете решить, проблема ли это.
Небольшое улучшение производительности:
perl -i -pe 'index($_, "$ARGV,") == 0 or print "$ARGV,"' file1 file2 ...
Среднее значение нагрузки охватывает не только процессы, использующие время ЦП или ожидающие его. Он также охватывает эти процессы в непрерывном спящем режиме (что обычно означает ожидание дискового ввода-вывода).
Деление на количество ЦП привело бы к некоторым странным (и часто бесполезным) числам. При наличии системы с 4 ядрами и 7 процессами, ожидающими одного диска, среднее значение нагрузки в соответствии с определением сходится к 1,75. Но это число ничего не значит. Деление на количество ядер при измерении связанной рабочей нагрузки ввода-вывода дало бы бессмысленный результат.
Конечно, можно вычислить среднее количество процессов, ожидающих ЦП, и среднее число процессов в режиме непрерывного сна. Сумма этих двух чисел будет традиционным средним значением нагрузки. Среднее число процессов, ожидающих ЦП, поделенное на число ЦП, также может быть значимым числом в некоторых контекстах.
Среднее число процессов в режиме бесперебойного сна, разделенное на количество дисков, однако, не будет значимым. В конце концов, пребывание в непрерывном спящем режиме не означает, какой диск он ждет, и также неясно, должно ли количество дисков также считать виртуальные устройства.
Вы не сказали, но я предполагаю, что это для Linux. Несмотря на то, что вы ищете историческую причину, по которой это происходит на ЦП, ваш вопрос указывает на то, что вы все еще думаете о средней нагрузке с точки зрения использования ЦП, а не об очереди заданий ядра, как это есть на самом деле. Вы по-прежнему можете видеть использование ЦП в таких программах, как top, если хотите увидеть% использования ЦП.
Если у вас 4 ядра ЦП, это означает, что ядро может ставить в очередь сразу 4 задачи для 4 ЦП. Таким образом, у вас будет 4+ багажа. Если ядро ставит в очередь больше задач после уже запущенных, то это число возрастает до 4. Это вообще не масштаб от 0 до 100%, и число увеличивается настолько, насколько необходимо, в зависимости от рабочей нагрузки. Однажды я увидел, что нагрузка превысила 15 000 из-за невыполненных заданий ввода-вывода в неисправной сетевой файловой системе. Номер будет сброшен после достижения 1024.