Ядро Linux в комментариях

       

Вычисление адекватности процесса


Адекватность (goodness) процесса вычисляется функцией goodness (строка ). Эта функция возвращает значение, относящееся к одному из двух классов: менее 1000 и свыше 1000. Значения от 1000 и выше присваиваются только процессам «реального времени», а значения от 0 до 999— только «обычным» процессам. В действительности значения адекватности для обычных процессов занимают только самую нижнюю часть этого диапазона от 0 до 41 (или от 0 до 56 для SMP, поскольку режим SMP предоставляет процессу дополнительную возможность оставаться в используемом процессоре). И для SMP, и для однопроцессорной системы значения адекватности процессов реального времени изменяются в диапазоне от 1001 до 1099.

Главная особенность такого разделения на классы заключается в том, что диапазон значений для процессов реального времени располагается над диапазоном значений, выделенным для процессов не реального времени (таким образом, смещение могло бы быть равным 100, а не 1000). Стандарт POSIX.1b делает ядро ответственным за то, чтобы процессам реального времени всегда отдавалось предпочтение перед процессами не реального времени, когда они конкурируют за доступ к процессору. Поскольку планировщик всегда выбирает процесс с наивысшим значением адекватности, и поскольку значение адекватности любого процесса реального времени, который еще не освободил процессор, всегда превосходит значение любого процесса не реального времени, позицию Linux в этом вопросе легко продемонстрировать.

Несмотря на заглавный комментарий над функцией goodness, эта функция никогда не возвращает значение –1000, ни какое-либо иное отрицательное значение. Бездействующий процесс имеет отрицательное значение переменной counter, поэтому функция goodness вернула бы отрицательное значение, если бы была вызвана с бездействующим процессом в качестве аргумента; но это никогда не происходит.

goodness — достаточно простая функция, хотя и является важной частью планировщика Linux. Она вызывается для каждого процесса в текущей очереди при каждом выполнении функции schedule и поэтому должна работать быстро. Но если она принимает неудачное решение, страдает вся система. Учитывая эти противоречия, думается, было бы трудно добиться лучшего результата, чем уже имеющийся.



Содержание раздела