Качество диспетчеризации и гарантии обслуживания

 Качество диспетчеризации  и гарантии обслуживания 

 Одна из проблем, которая возникает при выборе подходящей дисциплины обслуживания —  это гарантия обслуживания. Дело в  том, что в некоторых дисциплинах, например в дисциплине абсолютных приоритетов, низкоприоритетные процессы получаются обделенными многими ресурсами  и, прежде всего, процессорным временем. Возникает реальная дискриминация  низкоприоритетных задач, в результате чего они достаточно длительное время  могут не получать процессорное время. 3 конце концов, некоторые процессы и задачи вообще могут быть не выполнены  к заданному сроку. Известны случаи, когда вследствие высокой загрузки вычислительной системы отдельные  процессы вообще не выполнились, несмотря на то что прошло несколько лет (!) с момента их планирования. Поэтому  вопрос гарантии обслуживания является очень актуальным.

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

 Планирование  с учетом жестких временных ограничений  легко реализовать, организуя очередь  готовых к выполнению задач в  порядке возрастания их временных  ограничений. Основным недостатком  такого простого упорядочения является то, что задача (за счет других задач) может быть обслужена быстрее, чем  это ей реально необходимо. Чтобы  избежать этого, проще всего процессорное время выделять все-таки квантами. А  после получения задачей своего кванта времени операционная система, оценив некоторое множество факторов (важных с точки зрения оптимизации  распределения процессорного времени  и гарантий обслуживания к заданному  сроку), может переназначить приоритет  задаче. Это позволит ей более гибко  использовать механизм приоритетов  и иметь механизмы гарантии обслуживания.

 Гарантировать обслуживание можно, например, следующими тремя способами.

 Выделять минимальную  долю процессорного времени некоторому классу процессов, если по крайней мере один из них готов к исполнению. Например, можно отводить 20 % от каждых 10 мс процессам реального времени, 40 % от каждых 2 с — интерактивным  процессам и 10 % от каждых 5 мин —  пакетным (фоновым) процессам.

 Выделять минимальную  долю процессорного времени некоторому конкретному процессу, если он готов  к выполнению.

 Выделять столько  процессорного времени некоторому процессу, чтобы он мог выполнить  свои вычисления к сроку. 

 Для сравнения  алгоритмов диспетчеризации обычно используются некоторые критерии.

 Загрузка центрального процессора (CPU utilization). В большинстве персональных систем средняя загрузка процессора не превышает 2-3 %, доходя в моменты выполнения сложных вычислений и до 100 %. В реальных системах, где компьютеры (например, серверы) выполняют очень много работы, загрузка процессора колеблется в пределах от 15-40 % (для легко загруженного процессора) до 90-100 % (для тяжело загруженного процессора).

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

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

 Время ожидания (waiting time). Под временем ожидания понимается суммарное время нахождения процесса в очереди готовых процессов.

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

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

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

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

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

В случае мультипроцессорных систем применяются следующие методы повышения производительности системы:

совместное планирование, при котором все потоки одного приложения (неблокированные) одновременно ставятся на выполнение процессорами и одновременно снимаются с выполнения (для сокращения переключений контекста);

планирование, при  котором находящиеся в критической  секции задачи не прерываются, а активно  ожидающие входа в критическую  секцию задачи не ставятся на выполнение до тех пор, пока вход в секцию не освободится;

планирование с  учетом так называемых подсказок (hints) программы (во время ее выполнения), например, в известной своими новациями ОС Mach имелось два класса таких подсказок: во-первых, указания (разной степени категоричности) о снятии текущего процесса с процессора, во-вторых, указания о том процессе, который должен быть выбран взамен текущего.