CC BY
72
УДК 681.3
В. Ю. Егоров
НОВЫЕ ПОДХОДЫ К ДИСПЕТЧЕРИЗАЦИИ ЗАДАЧ В ОПЕРАЦИОННЫХ СИСТЕМАХ
Дается краткий сравнительный анализ дисциплин диспетчеризации задач, рассматриваются аппаратные средства поддержки диспетчеризации. По результатам анализа предлагается новый метод построения диспетчера задач на основе единой очереди заявок.
Введение
Несмотря на то, что в настоящее время вопросы построения диспетчера задач операционной системы как универсального, так и специального назначения, удовлетворяющего многочисленным требованиям, изучены достаточно глубоко, остается ряд вопросов, подлежащих рассмотрению.
При выборе метода, согласно которому следует реализовывать диспетчер задач интерактивной операционной системы, разработчик сталкивается с определенными трудностями, поскольку до настоящего времени не существует дисциплины диспетчеризации, однозначно признанной лучшей. Все эксперты сходятся во мнении о необходимости применения вытесняющей многозадачности и карусельного (round robin) принципа диспетчеризации для реализации вычислительной среды. Однако остается ряд вопросов, на которые нет четкого ответа. Как должна быть реализована обработка прерываний: с относительными или абсолютными приоритетами? Какими критериями следует руководствоваться при выборе дисциплины диспетчеризации? Предлагаемая статья описывает один из способов реализации диспетчера задач операционной системы.
1 Краткий обзор дисциплин диспетчеризации
Как известно, все дисциплины диспетчеризации подразделяются на два крупных класса - бесприоритеные и приоритетные. Бесприоритетные дисциплины диспетчеризации обусловливают крайне низкую скорость реакции системы на входящие запросы, а потому должны быть сразу отброшены. Приоритетные дисциплины диспетчеризации в свою очередь подразделяются на дисциплины со статическими и динамическими приоритетами.
Дисциплины со статическими приоритетами предполагают, что приоритет события, возникающего в системе, должен быть определен заранее и должен оставаться неизменным в течение всего времени работы системы. Дисциплины с динамическими приоритетами, напротив, декларируют непрерывную корректировку приоритета события. Каждый из подходов имеет и достоинства и недостатки.
Как показывает практика, событие, однажды определенное как требующее немедленной реакции системы, продолжает оставаться таковым постоянно. К таким событиям можно отнести, например, необходимость подготовки новой порции данных для контроллера прямого доступа к памяти в составе накопителя на жестких дисках или сетевого адаптера. Малейшее увеличение времени реакции здесь приводит к резкому снижению пропускной способности всей операционной системы. К тому же на изменение приоритета задачи, будь то
программный или аппаратный способ реализации, уйдет значительное по меркам современных вычислительных систем время. Это позволяет сделать вывод о преимуществе системы со статическими приоритетами.
С другой стороны, постоянно высокий приоритет прикладной задачи приводит к реальной дискриминации низкоприоритетных задач в составе операционной системы. Здесь более уместно говорить о превосходстве дисциплины диспетчеризации с динамическими приоритетами.
Разработчики современных операционных систем нашли выход из положения в виде системы со смешанными приоритетами (рис. 1). При таком способе диспетчеризации весь интервал приоритетов разбивается на две части. Интервал более высоких приоритетов, предназначенный для функционирования аппаратных устройств компьютера, реализуется как дисциплина со статическими приоритетами. В литературе значения этого интервала обозначаются как IRQL (Interrupt Request Level). Такое название было применено при разработке операционной системы Windows. Низкоприоритетный интервал отводится для функционирования прикладных задач и реализуется как одна из дисциплин с динамическими приоритетами. В литературе значения этого интервала именуются английским словом Priority (собственно приоритет). Сказанное иллюстрируется на рис. 1.
HIGH
Я
&
MINIMAL DEVICE INTERRUPT DISPATCH
См
APC
Максимальный приоритет прикладного процесса
Минимальный приоритет прикладного процесса
Приоритет простоя
Рис. 1 Отношение аппаратных и программных приоритетов
Следует рассмотреть еще один вопрос, касающийся механизма диспетчеризации: если используются статические аппаратные приоритеты, то какую дисциплину обработки аппаратных прерываний следует выбрать - с относительными или с абсолютными приоритетами? В классическом варианте диспетчеризации, реализованном в операционной системе UNIX (в настоящее время - в Linux), для верхних половинок обработчиков прерываний (top half) использовались относительные приоритеты. В операционной системе Windows, напротив, используются абсолютные приоритеты прерываний. И та и другая системы обладают примерно равноценным быстродействием. Следовательно, можно утверждать, что влияние выбора той или иной системы приоритетов для обработки прерываний незначительно.
2 Современная аппаратная поддержка диспетчеризации задач
Современные аппаратные средства в составе компьютера предоставляют возможность аппаратной поддержки для реализации диспетчера задач операционной системы. В основном это касается механизмов обслуживания прерываний. Все современные компьютеры, работающие на платформе IA-32, имеют в своем составе расширенный контроллер прерываний - APIC (Advanced Programmable Interrupt Controller).
Контроллер APIC состоит из двух частей (рис. 2). Одна - в составе центрального процессора, называемая Local Apic, вторая - в составе одной из микросхем материнской платы компьютера, называемая IoApic. И Local Apic, и IoApic могут присутствовать в системе в нескольких экземплярах. Каждый IoApic имеет в своем составе некоторое количество линий (обычно 24), используемых как входы прерываний аппаратных устройств. Если объединить несколько IoApic, то можно значительно увеличить количество входов. В современных серверах имеется более пятидесяти линий для подключения сигналов прерываний от аппаратных устройств. Таким способом достигается расширение числа аппаратных прерываний от подключаемых устройств.
Рис. 2 Организация расширенного контроллера прерываний
Отличительной особенностью контроллера является то, что понятие IRQL в нем введено аппаратно. Такая организация позволяет обрабатывать прерывания значительно быстрее. При возникновении сигнала прерывания контроллер APIC переключает процессор на обработку прерывания и аппаратно повышает IRQL до уровня, заданного при установке обработчика на прерывание. После этого могут возникнуть только прерывания, уровень IRQL которых выше, чем текущий. Те сигналы прерываний, чей IRQL ниже или равен текущему, остаются ожидать понижения IRQL, выполняемого операционной системой по завершении обработчика прерывания. При таком способе естественной оказывается дисциплина обработки прерываний с абсолютными приоритетами.
2 Проблемы обслуживания заявок
Стандартная схема организации диспетчера задач, реализующего приоритетную дисциплину обслуживания, включает в себя набор очередей (рис. 3), в котором одна очередь хранит заявки на исполнение с одним и тем же приоритетом. Заявки поступают от нитей (threads) процессов (часто в пе-
5s
реводной литературе называемых потоками). Сначала обслуживаются заявки с максимальным приоритетом (например, 32), затем рассматривается очередь с приоритетом 31 и т.д.
Рис. 3 Очереди задач по приоритетам
Для аппаратных приоритетов (ІЯОЬ) такая схема является оптимальной, поскольку обеспечивает приемлемое время реакции для всех типов аппаратных устройств. Однако для обслуживания заявок с нулевым аппаратным приоритетом, при котором начинает играть роль программный приоритет, возникают проблемы, связанные с качеством и гарантиями обслуживания. Необходимо, чтобы заявка с любым, пусть даже самым низким, приоритетом была обслужена в приемлемое время. В противном случае существует реальная вероятность сценария, при котором заявки с низким приоритетом никогда не будут выбраны. Сформулируем основные требования к дисциплине диспетчеризации современной операционной системы:
1) любая задача должна получать часть процессорного времени для своего выполнения (требование гарантии обслуживания);
2) любая задача должна получать долю процессорного времени в соответствии со своим приоритетом и общей загруженностью центрального процессора (первое требование качества обслуживания);
3) процессорное время должно выделяться каждой задаче с некоторой периодичностью, позволяющей имитировать непрерывность выполнения задачи (второе требование качества обслуживания);
4) задаче, в интерактивном режиме взаимодействующей с пользователем, должно выделяться больше процессорного времени, чем задаче, выполняющейся в фоновом режиме (требование адаптивности обслуживания).
Удовлетворение данных требований приводит к тому, что алгоритм выбора следующей заявки на обслуживание задачи значительно усложняется и становится нетривиальным. В данной статье предлагается вариант реализации диспетчера задач, позволивший упростить и схему реализации, и алгоритм работы приоритетной дисциплины обслуживания.
3 Организация диспетчера задач в виде односвязного списка
Основная идея предлагаемого метода заключается в отказе от множества очередей заявок на обслуживание в пользу схемы, в которой реализована только одна очередь задач. Чтобы такая схема стала возможной, в структуру нити необходимо добавить дополнительное поле, которое будет регулировать
очередность обслуживания заявки. Назовем это поле «текущим количеством приоритета» заявки (т), в отличие от текущего приоритета (є) и базового приоритета заявки (а). Текущий приоритет заявки є - это целое беззнаковое число, значение которого может отклоняться от базового приоритета заявки в меньшую или большую сторону, в зависимости от текущего состояния операционной системы. Если процесс, ждущий квант процессорного времени, выполняется в фоновом режиме, то его приоритет снижается по сравнению с базовым приоритетом. Если процесс находится в интерактивном режиме взаимодействия с пользователем, то его текущий приоритет повышается относительно базового приоритета. Текущее количество приоритета заявки т -это также целое беззнаковое число, служащее для расчета места заявки в очереди, значение которого никогда не может быть больше, чем текущий приоритет заявки:
т<є. (1)
Заявка q в любой момент времени характеризуется тремя значениями: базовым приоритетом а, текущим приоритетом є и текущим количеством приоритета т. Будем обозначать заявку в очереди как qа,є,т. Очередь заявок, ожидающих обслуживания, будем обозначать как й.
Весь алгоритм диспетчера задач при реализации данного метода разбивается всего на две функции, подлежащие реализации: функция добавления
заявки в очередь /,и1 |й, qa,є,тj и функция выбора следующей заявки из очереди с целью обслуживания /^еХ |й, qa,є,т |.
Функция извлечения заявки /^еХ |й, qa,є,т | очень проста. При необходимости помещения заявки на обслуживание нужно просто взять первую заявку из головы очереди. Именно она будет являться оптимальной заявкой с точки зрения гарантий и качества обслуживания. Функция /ри1 |й, qa,є,т | сложнее. Она
рассчитывает место заявки в очереди заявок исходя из базового и текущего приоритета как самой заявки, так и заявок, уже находящихся в очереди. Ниже приведен упрощенный словесный алгоритм функции /ри1 |й, qa,є,т |.
1. Проверить, нет ли данной заявки уже в очереди заявок. Если есть, то алгоритм завершен.
2. Если текущее количество приоритета т заявки не равно нулю, то перейти к пункту 4. Иначе сделать значение т заявки равным ее текущему приоритету є и перейти к пункту 3.
3. Поставить заявку в конец очереди заявок. Алгоритм завершен.
4. Уменьшить т заявки на единицу.
5. Взять первую заявку из головы списка qг■.
6. Если значение т заявки qi меньше, чем значение т добавляемой заявки, то перейти к пункту 8. Иначе взять следующую заявку qг■+1 по списку и повторить пункт 6.
7. Если по итогам поиска не нашлось заявок, удовлетворяющих условию, то перейти к пункту 3.
8. Поставить добавляемую заявку в очередь перед найденной заявкой qг■. Алгоритм завершен.
В результате выполнения данного алгоритма в качестве функции
/ри1 |й, qа,є,т | все заявки, поступающие на вход диспетчера задач, будут гарантированно обслужены. При этом сохраняется отношение приоритетов, т.е. заявки с более высоким приоритетом будут обслуживаться чаще, чем заявки с более низким приоритетом.
При работе алгоритма в каждой обслуживаемой задаче происходит постепенное снижение значения т до нуля. Если исходное значение є было больше, то и количество квантов, полученное заявкой до того, как ее значение т станет равным нулю, также будет больше. После того, как значение т всех задач достигнет нуля, цикл повторяется.
Алгоритм позволяет производить динамическое изменение как значения т заявки, так и значения є. Значение т имеет смысл однократно увеличивать после окончания операции ввода-вывода этой задачи для более быстрого взаимодействия с аппаратными устройствами. При активизации процесса на экране пользователя значение є всех нитей процесса следует повысить на 1 или 2 пункта. Вследствие такого повышения облегчается интерактивное взаимодействие с пользователем.
К минусам алгоритма можно отнести наличие массовой операции поиска места для добавляемой заявки. Однако, как показывает практика, в очереди диспетчера задач подавляющее количество времени находится не более двух-трех заявок на обслуживание. Это происходит из-за того, что большая часть задач в системе находится в других очередях - в очередях к объектам синхронизации, таким как события, семафоры и т.п.
В процессе работы операционной системы часто может возникнуть ситуация, при которой очередь й центрального процессора будет пуста. При возникновении такой ситуации следует решить, что должен делать центральный процессор. Первый вариант решения - останов процессора (например, с помощью инструкции Ьк в архитектуре ІА-32). При таком останове процессора его работа возобновляется только после возникновения какого-либо аппаратного прерывания. Поскольку прерывание таймера, ограничивающее квант времени процессора, также относится к аппаратным прерываниям, то максимальная длительность одного останова не может быть дольше кванта процессорного времени. Использование данного способа позволяет снизить энергопотребление компьютера, а также уменьшить тепловыделение центрального процессора.
Существует и другой вариант - создать в системе особую задачу, которая будет выполняться только в том случае, когда очередь й пуста. Эта задача может выполнять действия, подготавливающие операционную среду к работе. К таким действиям можно отнести, например, обнуление страниц физической памяти, чтобы этого не делать в процессе выделения страниц. Перед обнулением страницы можно также протестировать на отсутствие аппаратных сбоев. Возможен также третий, смешанный, вариант - когда в каждом свободном кванте времени центральный процессор будет обнулять только одну страницу физической памяти, а затем останавливаться до следующего аппаратного прерывания или до конца кванта.
4 Снижение затрат на переключение адресных пространств
Во время работы операционной системы постоянно возникает необходимость переключения между адресными пространствами процессов. Когда активизируется нить, принадлежащая какому-либо процессу, необходимо, чтобы ее выполнение происходило в адресном пространстве этого процесса. В общем случае для этого требуется переключить адресное пространство от текущего процесса ко вновь выбранному. Для операционных систем, работающих в архитектуре ІА-32, для этого необходимо как минимум перегрузить таблицу страниц процесса. Для центрального процессора работа по переключению адресных пространств есть весьма трудоемкая задача. На ее выполнение уходит около полутора тысяч тактов процессора. Одним из способов уменьшения частоты переключения адресных пространств и, как следствие, повышения производительности системы является расположение заявок на обслуживание таким образом, чтобы подряд выполнялись нити одного и того же процесса, затем нити следующего процесса и т.д. Если две нити одного процесса будут выполняться подряд, то при переключении между этими нитями не нужно будет переключать адресное пространство процесса. Таким образом, производительность системы повысится.
Для того чтобы добиться такого повышения производительности, необходимо внести изменения в пункт 6 рассмотренного выше алгоритма. После внесения изменения пункт будет выглядеть следующим образом: «6. Если значение т заявки qi меньше, чем значение т добавляемой заявки, то перейти к пункту 8. Если значение т заявки qi равно значению т добавляемой заявки и обе заявки принадлежат одному процессу, то также перейти к пункту 8. Иначе взять следующую заявку qi+1 по списку и повторить пункт 6».
Такой алгоритм приводит к тому, что в результате все заявки одного процесса начинают выполняться подряд. Затем выполняются все заявки другого процесса и т.д. Как следствие, производительность системы повышается за счет уменьшения количества переключений между адресными пространствами процессов.
Заключение
На основе существующих на данный момент аппаратных механизмов в составе ядра процессора и микросхем материнской платы архитектуры ІА-32 удается построить диспетчер задач операционной системы, удовлетворяющий многочисленным предъявляемым требованиям. В современных операционных системах диспетчер задач делится на две обособленные части: обслуживание прерываний от аппаратуры компьютера с использованием аппаратных приоритетов и диспетчеризация заявок на обслуживание с использованием программных приоритетов. В статье предлагается простой алгоритм диспетчера задач, позволяющий осуществлять диспетчеризацию заявок на обслуживание с использованием программных приоритетов. К особенностям алгоритма относятся:
• использование единой очереди заявок на обслуживание;
• реализация приоритетной дисциплины обслуживания заявок;
• простота реализации алгоритма;
• возможность динамического изменения приоритета заявок.
Предложенный алгоритм диспетчеризации заявок на обслуживание может
быть использован при разработке операционной системы общего назначения.
Список литературы
1. Соломон, Д. Внутреннее устройство Microsoft Windows 2000. Мастер-класс : пер. с англ. I Д. Соломон, М. Руссинович. - СПб. : Питер ; Издательско-торговый дом «Русская редакция», 2001. - 752 с.
2. Таненбаум, Э. Современные операционные системы I Э. Таненбаум. - 2-е изд. -СПб. : Питер, 2002. - 1040 с.
3. IA-32 Intel Architecture Software Developers Manual. Volume 3: System Programming Guide (www.intel.com).
4. BIOS and Kernel Developers Guide for AMD Athlon б4 and AMD Opteron Processors. Rev. 3.2S October 2005 (www.amd.com).
5. Intel S2371FB (PIIX) AND S2371SB (PIIX3) PCI ISA IDE XCELERATOR. April 1997 (www.intel.com).
6. Цилькер, Б. Я. Организация ЭВМ и систем : учебник для вузов I Б. Я. Циль-кер, С. А. Орлов - СПб. : Питер, 200б. - 66S с.
7. Робачевский, А. М. Операционная система UNIX I А. М. Робачевский. -СПб. : БХВ-Санкт-Петербург, 1999. - 52S с.
S. Гордеев, А. В. Системное программное обеспечение I А. В. Гордеев, А. Ю. Молчанов. - СПб. : Питер, 2001. - 736 с.
9. Бек, Л. Введение в системное программирование : пер. с англ. I Л. Бек. - М. : Мир, 19SS. - 44S с.
