при каких условиях лучше увеличить time slice планирования а когда лучше уменьшить

Принцип работы планировщика задач в Linux

Планирование – это процесс распределения ресурсов системы для выполнения задач. В статье мы рассмотрим его вариант, в котором ресурсом является одно или несколько ядер процессора, а задачи представлены потоками или процессами, которые нужно выполнить.

Само планирование осуществляется планировщиком, который нацелен:

Типы процессов в Linux

В Linux процессы делятся на два типа:

В качестве примера можно привести процесс переноса, отвечающий за распределение рабочей нагрузки между ядрами ЦПУ.

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

В пример можно привести процесс браузера, который позволяет вам читать эту статью.

У каждого типа процессов есть свой алгоритм планирования. При этом пока есть готовые к выполнению процессы реального времени, выполняться будут они, оставляя условные процессы в ожидании.

Планирование в реальном времени

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

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

SCHED_FIFO

В данной политике планировщик выбирает процесс, ориентируясь на время его поступления (FIFO = первым вошел, первым вышел).

Процесс с политикой планирования SCHED_FIFO может «освободить» ЦПУ в нескольких случаях:

SCHED_RR

SCHED_RR подразумевает циклическое планирование.

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

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

Обобщение по планированию в реальном времени

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

Условное планирование

Здесь мы знакомимся с Completely Fair Scheduler (CFS, абсолютно справедливый планировщик), представляющим алгоритм планирования условных процессов, появившийся в версии Linux 2.6.23.

Помните метрики планирования, которые мы затронули в начале статьи? Так вот CFS фокусируется на одной из них – он стремится к максимальной равноправности процессов, то есть обеспечивает выделение всем процессам равных квантов времени ЦПУ.

Обратите внимание, что процессы с повышенным приоритетом все равно могут получать на обработку больше времени.

Для лучшего понимания принципа работы CFS нужно познакомиться с новым термином – виртуальное время выполнения ( vruntime ).

Виртуальное время выполнения

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

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

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

CFS —Абсолютно справедливый планировщик

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

Когда процесс исчерпывает свой интервал ( Qi ), алгоритм выбирает в дереве следующий процесс с наименьшим виртуальным временем.

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

Предположим, что алгоритм выбрал лимит времени 48мс при наличии 6 процессов – в этом случае каждый процесс получит на выполнение по 8мс.

Но что произойдет, если система окажется перегружена процессами? Предположим, что лимит времени остается равен 48мс, но теперь у нас 32 процесса. В результате каждый получит уже всего по 1.5мс на выполнение, что приведет к замедлению работы всей системы.

Почему?

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

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

Предположим, что на него уходит 1мс. В первом примере, где каждому процессу у нас отводилось по 8мс, это вполне допустимо. Так мы тратим 1мс на переключение контекста и 7мс на фактическое выполнение процесса.

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

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

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

Надеюсь, что статься помогла вам лучше понять реализацию планирования задач в ядре Linux.

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

Источник

Вся правда об ОСРВ от Колина Уоллса. Статья #3. Задачи и планирование

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

Предыдущие статьи серии:
Статья #2. ОСРВ: Структура и режим реального времени
Статья #1. ОСРВ: введение.

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

Многие ОСРВ, применяемые во встраиваемых приложениях, используют многопоточную модель. Одновременно может выполняться несколько потоков, занимающих одно адресное пространство:

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

Альтернативой является многопроцессная модель. Если выполняется несколько процессов, то у каждого процесса есть свое адресное пространство и нельзя обращаться к памяти, связанной с другими процессами или ОСРВ:

Это делает переключение контекста более сложным и затратным по времени, так как операционная система должна соответствующим образом настроить блок управления памятью, диспетчера памяти (англ. Memory Management Unit, MMU). Конечно, подобная архитектура возможна только при наличии процессора, который поддерживает MMU. Процессы поддерживаются «высокопроизводительными» ОСРВ и большинством десктопных ОС. Более того, каждый процесс может поддерживать разделение на несколько потоков, но это свойство редко используется в обычных встраиваемых приложениях.

Если доступен MMU, можно достичь компромисса:

Многие «потоковые» ОСРВ поддерживают MMU для защиты памяти от несанкционированного доступа. Таким образом, пока задача находится в контексте, «видны» только часть ее кода/данных и необходимые участки ОСРВ; остальные блоки памяти отключены, а попытка доступа вызовет нештатную ситуацию (для обычных людей)/исключение (для программистов). Это делает переключение контекста немного сложнее, но само приложение более безопасным. Такой режим можно назвать «Режим Защищенных Потоков» (Thread Protected Mode) или «Упрощенная модель процессов» (Lightweight Process Mode).

Планировщики

Как мы знаем, иллюзия одновременного исполнения задач достигается за счет выделения процессорного времени для выполнения каждой из задач. Это основная функция ядра. Способ распределения времени между задачами называется «планирование». Планировщик —программное обеспечение, которое определяет, какой следующей задаче передать управление. Логика планировщика и механизм, определяющий, когда и что должно выполняться, — алгоритм планирования. В этом разделе мы рассмотрим несколько алгоритмов планирования. Планирование задач — обширная тема, и ей посвящено множество книг. Мы предоставим необходимый минимум, чтобы понять, что конкретная ОСРВ может предложить в этом отношении.

Планировщик Run to Completion (RTC)

Планировщик RTC (run-to-completion – «выполнение до завершения») очень прост и расходует ресурсы минимально. Это идеальный сервис, если он соответствует требованиям приложения. Ниже график для системы, использующей планировщик RTC:

Планировщик по очереди вызывает функции верхнего уровня каждой задачи. Задача управляет процессором (прерывает его) до тех пор, пока функция верхнего уровня не выполнит оператор возврата return. Если ОСРВ поддерживает приостановку задач, то любые задачи, приостановленные в текущее время, не выполняются. Это тема рассматривается в статье ниже, см. «Приостановка задачи».

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

Планировщик Round Robin (RR)

Планировщик RR («карусель») похож на RTC, но более гибкий и, следовательно, более сложный:

Тем не менее, в случае планировщика RR у задачи нет необходимости выполнять оператор return в функции верхнего уровня. Она может освободить процессор в любое время, сделав вызов ОСРВ. Этот вызов приводит к тому, что ядро сохраняет контекст текущей задачи (все регистры, включая указатель стека и указатель команд) и загружает контекст следующей в очереди задачи. В некоторых ОСРВ процессор можно освободить (приостановить задачу) в ожидании доступности ресурса ядра. Это сложнее, но принцип тот же.

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

Планировщик Time slice (TS)

Планировщик TS (time slice — «квант времени») на уровень сложнее RR. Время поделено на слоты (интервалы, кванты времени), где каждая задача может выполняться внутри назначенного ей интервала:

Помимо возможности добровольно освобождать процессор, задача может быть прервана вызовом планировщика, выполненным обработчиком прерываний системного таймера. Идея назначения каждой задаче фиксированного временного отрезка очень привлекательна (там, где это возможно): в ней легко разобраться, и она очень предсказуема.
Недостаток планировщика TS в том, что доля процессорного времени, выделенного для каждой задачи, может отличаться, в зависимости от того, приостановлены ли другие задачи и свободны ли другие части слотов:

Более предсказуемым планировщик TS может стать, если реализована работа задач в фоновом режиме. Фоновая задача может выполняться вместо любой приостановленной задачи и занимать временной интервал, когда задача освобождается (либо приостанавливает сама себя).

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

Подобное решение предполагает, что каждая задача может предсказывать, когда она будет запланирована снова. Например, если у вас есть слоты на 10 мс и 10 задач, задача знает, что, если она освободится, то продолжит выполнение через 100 мс. С помощью этого решения можно добиться более гибкой настройки временных циклов (таймингов) для задач приложений.
ОСРВ может предоставлять различные временные интервалы для каждой задачи. Это обеспечивает большую гибкость, но также предсказуемо, как и при фиксированном размере интервала. Другой вариант — выделить более одного интервала для одной и той же задачи, если нужно увеличить долю выделенного процессорного времени.

Приоритетный планировщик (Priority Scheduler)

Большинство ОСРВ поддерживают планирование на основании приоритетов. Идея проста: каждой задаче присваивается приоритет, и в любой момент задача, которая имеет наивысший приоритет и «готова» к выполнению, передается процессору:

Планировщик запускается, когда происходит какое-то событие (например, прерывание или вызов определенной службы ядра), которое вынуждает задачу с высоким приоритетом становиться «готовой». Есть три обстоятельства, при которых начинает работать планировщик:
• Задача приостанавливается; планировщик должен назначить следующую задачу.
• Задача подготавливает более приоритетную задачу (с помощью вызова API).
• Обработчик прерываний (англ. Interrupt Service Routine, ISR) подготавливает более приоритетную задачу. Это может быть обработчик прерываний устройства ввода/вывода или результат срабатывания системного таймера.
Количество уровней приоритета варьируется (от 8 до нескольких сотен), также разнятся пороговые значения: некоторые ОСРВ воспринимают наивысший приоритет как 0, а в других же 0 обозначает низший приоритет.
Некоторые ОСРВ допускают только одну задачу на каждом уровне приоритетов; другие разрешают несколько, что значительно усложняет связанные с этим структуры данных. Многие операционные системы позволяют изменять приоритеты задач во время выполнения, что еще больше усложняет процессы.

Комбинированный планировщик (Composite Scheduler)

Мы рассмотрели несколько планировщиков, однако многие коммерческие ОСРВ предлагают еще более изощренные решения, обладающие характеристиками сразу нескольких алгоритмов. Например, ОСРВ может поддерживать несколько задач на каждом уровне приоритета, а затем использовать TS, чтобы разделить время между несколькими готовыми задачами на самом высоком уровне.

Состояния задач

В любой момент времени выполняется только одна задача. Помимо процессорного времени, затрачиваемого на обработчика прерываний (подробнее об этом в следующей статье) или планировщика, «текущей» задачей является та, чей код выполняется в настоящее время и чьи данные характеризуются текущими значениями регистра. Могут быть и другие задачи, «готовые» к запуску, и они будут учитываться планировщиком. В простой ОСРВ, использующей планировщик RTC, RR или TS, это всё. Но чаще, и всегда с Priority-планировщиком, задачи могут также находиться в приостановленном состоянии, что означает, что они не учитываются планировщиком до тех пор, пока не будут возобновлены и не перейдут в состояние «готовности».

Приостановка задачи

Приостановка задачи может быть довольно простой: задача приостанавливается самостоятельно (вызовом API) или другая задача приостанавливает ее. Через другой вызов API приостановленная задача может быть возобновлена другой задачей или обработчиком прерываний. Это «безусловная» (unconditional) или «чистая» (pure) приостановка. Некоторые операционные системы называют такую задачу «спящей».

ОСРВ может предоставлять задаче возможность приостанавливаться (засыпать) на определенный период времени, по истечении которого она возобновляется (по системным часам). Это можно назвать «засыпанием».

Если ОСРВ поддерживает «блокирующие» вызовы API, можно использовать более сложное приостановление. Такой вызов позволяет задаче запросить службу или ресурс, который она немедленно получит в случае его доступности. В противном случае она будет приостановлена до тех пор, пока он не станет доступным. Также могут быть определены таймауты, при которых задача возобновляется, если ресурс недоступен в определенный период времени.

Другие состояния задач

Многие ОСРВ поддерживают другие состояния, но понятия и определения сильно разнятся. Например, состояние «finished», которое просто означает, что внешняя функция задачи вышла (либо выполнив возврат кода, либо только закончив внешний функциональный блок). Для того чтобы завершенная задача снова начала выполняться, ее, вероятно, нужно будет каким-то образом сбросить.

Другой вариант — это состояние «terminated». Это похоже на полную приостановку (pure), за исключением того, что задача должна быть возвращена в исходное состояние для повторного запуска.

Если ОСРВ поддерживает динамическое создание и удаление задач (см. след. статью), это подразумевает другое возможное состояние задачи — «deleted».

Когда мы работали над нашей собственной операционной системой реального времени ОСРВ МАКС (ранее уже публиковал статьи о ней), наша команда «наткнулась» на блог Колина Уоллса (Colin Walls), эксперта в области микроэлектроники и встроенного ПО компании Mentor Graphics. Статьи показались интересными, переводили их для себя, но, чтобы не «писать в стол» решили опубликовать. Надеюсь, они будут вам также полезны. Если так, то дальше планируем опубликовать все переведенные статьи серии.

Об авторе: Колин Уоллс уже более тридцати лет работает в сфере электронной промышленности, значительную часть времени уделяя встроенному ПО. Сейчас он – инженер в области встроенного ПО в Mentor Embedded ( подразделение Mentor Graphics). Колин Уоллс часто выступает на конференциях и семинарах, автор многочисленных технических статей и двух книг по встроенному ПО. Живет в Великобритании. Профессиональный блог Колина: blogs.mentor.com/colinwalls, e-mail: colin_walls@mentor.com

Первая и вторая статьи цикла размещены здесь.

Источник

Русские Блоги

[Linux] Linux 2.6 улучшения в планировщике

С точки зрения планирования процессов, версия до Linux2.6 имеет следующие недостатки:

В ответ на эти предыдущие проблемы Linux 2.6 сосредоточился на улучшении алгоритма планировщика с самого начала разработки.

Готовая очередь процесса

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

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

Как вы можете видеть на картинке выше,После улучшения каждый процессор имеет две группы очередей процессов, активную группу очередей и группу очередей с истекшим сроком действия. Процессы в каждой группе очередей классифицируются по приоритетным процессам, каждый тип процесса является очередью, и в группе может быть до 140 очередей.

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

Рабочий процесс готовой очереди процессов Linux 2.6 примерно такой: когда временной интервал процесса в массиве [0] исчерпан, он будет удален из массива [0] сразу после того, как система переназначит временной интервал и приоритет для него. И вставляется в соответствующую очередь в массиве [1] в соответствии со своим приоритетом, чтобы он больше не мог участвовать в этом раунде планирования. Таким образом, когда временные интервалы всех процессов в массиве [0] исчерпаны, текущий раунд планирования также заканчивается, и все процессы вошли в массив [1], готовый к следующему раунду планирования. Это связано с тем, что системе нужно просто переключать активные и просроченные указатели, используя array [1] в качестве очереди планирования и array [0] в качестве очереди буфера для непосредственного входа в следующий раунд планирования.

Очередь процессов процессора в начале и в конце цикла планирования показана ниже:

Поскольку в системе часто много готовых процессов, то как быстро найти готовые процессы для запуска, становится важным фактором, связанным с производительностью системы. к этому концу,В Linux 2.6 настраивается битовая карта состояния готовности в порядке приоритета для каждой группы очередей процессов. Каждый бит битовой карты соответствует очереди процессов.Если в очереди есть готовые процессы, соответствующий бит в битовой карте помечается как 1, в противном случае он равен 0. Таким образом, планировщику не нужно искать процесс, который нужно запустить, используя трудоемкий и постоянный во времени метод обхода очереди, а просто просматривая таблицу.

Чтобы описать вышеупомянутую структуру очереди, Linux определяет данные структуры структуры очереди выполнения для каждого процессора:

Для ясности перечислена только самая важная часть структуры: массив array [] типа prio_array и два указателя active и expired. Среди них структура данных prio_array выглядит следующим образом:

Среди них: MAX_PRIO 140, BITMAP_SIZE 5, long 32 бита.

Два указателя, активные и истекшие в очереди выполнения, указывают на элементы массива array [0] и array [1] array array [], соответственно. Каждый из элементов массива array [0] и array [1] имеет очередь массива очереди процессов [] с приоритетом процесса (MAX_PRIO> i> = 0) в качестве нижнего индекса, где каждый элемент хранит очередь процесса Заголовок связанного списка и процессы в каждом связанном списке имеют одинаковый приоритет.

Если массив [] процессора такой, как показано ниже:

Например, очередь [1] в массиве [0] является готовой очередью процесса с приоритетом 1, и временной интервал не исчерпан, в то время как очередь [1] в массиве [1] готова с приоритетом 1 и временной интервал был исчерпан. Очередь процессов.

Приведенный выше метод организации очереди предоставляет мощную гарантию для реализации в Linux O 2.6 алгоритма планирования O (1), так что накладные расходы планировщика не зависят от текущей загрузки системы (числа процессов). Наивысший приоритет поисковой системы в алгоритме O (1) преобразуется в первый бит, установленный в 1 в битовой карте приоритета поиска. В отличие от ядра Linux 2.4, которое сравнивает вес каждого процесса по очереди, поскольку число приоритетов процесса является фиксированным значением, время нахождения наилучшего приоритета является постоянным, и на него не будет влиять количество исполняемых процессов, как в предыдущем методе.

То есть: версия алгоритма планирования ядра для Linux 2.4 проста для понимания: при каждом переключении процесса ядро ​​последовательно сканирует каждый процесс в очереди готовности, вычисляет вес каждого процесса и затем выбирает процесс с наибольшим весом для запуска. Хотя этот алгоритм прост для понимания, время, которое он тратит на выбор процесса с наибольшим весом, нельзя игнорировать. Чем больше процессов может выполняться в системе, тем больше времени требуется, и сложность времени составляет O (n).

Алгоритм O (1), используемый ядром Linux 2.6, решает эту проблему очень хорошо.Алгоритм может перераспределять временные интервалы для каждого процесса в постоянное время и может выбирать наивысший приоритет в постоянное время Важно, чтобы эти два процесса не имели отношения к числу процессов, которые могут быть запущены в системе, поэтому алгоритм называется O (1).

Очередь готовых процессов многопроцессорной системы Linux 2.6 показана на рисунке ниже:

Кроме того, в Linux 2.6 были сделаны две относительно большие реформы в планировании процессов: во-первых, необходимо переместить вычисления приоритетов процессов, которые изначально были сосредоточены в планировщике, за пределы планировщика, и Работайте, просто выберите процесс, который нужно запустить, непосредственно из массива очередей с приоритетами, который был отсортирован по алгоритму, второй пункт заключается в том, что для нужд встроенных систем Linux 2.6 позволяет планировать состояние системы.

Метод расчета приоритета

Поля, связанные с вычислением приоритета процесса в печатной плате

В Linux 2.6 были внесены серьезные изменения в поля в блоке управления процессом, которые связаны с уровнем приоритета процесса вычисления. Некоторые просто изменили имя исходного домена, а некоторые имеют принципиально иное значение, чем Linux 2.4.

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

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

Динамический приоритет prio

prio эквивалентен весу результата вычисления goodness () в Linux 2.4,Это является основой для планировщика, чтобы выбрать запущенный процесс в готовом процессе. Поскольку он рассчитывается путем объединения различных факторов, он также называется динамическим приоритетом процесса.

MAX_PRIO-1. Чем меньше значение, тем выше приоритет. Обычно MAX_RT_PRIO-1 = 99 и MAX_PRIO-1 = 139. То есть 0

99 принадлежит диапазону значений приоритета процесса в реальном времени, а 100

139 принадлежит диапазону значений приоритета процесса не в реальном времени.

Когда Linux 2.6 вычисляет динамический приоритет prio для процесса, он добавляет соответствующий бонус (вознаграждение) на основе статического static static_prio, которое в основном не изменяется. То есть он связан с двумя параметрами static_prio и bonus:

Статический приоритет

static_prio является членом блока управления процессом, и его диапазон значений составляет 0

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

19), чем больше значение, тем ниже приоритет процесса.

Отношения между static_prio и nice следующие:

static_prio=MAX_RT_PRIO+nice+20

На следующем рисунке показана связь между static_prio и nice:

Следует отметить, что Linux 2.6 больше не использует nice в качестве домена PCB.

Среднее время ожидания процесса sleep_avg

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

Поскольку интерактивный процесс в основном связан с периферийными устройствами, планировщик определяет, является ли процесс интерактивным процессом, на основе времени ожидания процесса: как только он считается интерактивным процессом, планировщик предоставит ему некоторый «поощрительный» бонус с точки зрения приоритета, тогда как sleep_avg Это фактор, используемый для расчета суммы вознаграждения.

sleep_avg является важной основой для расчета бонуса фактора бонуса, и взаимосвязь между ними показана на следующем рисунке:

Можно видеть, что приоритет процесса не в реальном времени определяется только статическим приоритетом (static_prio) и значением sleep_avg процесса.Среди них sleep_avg отражает две стратегии системы планирования: приоритет интерактивного процесса и справедливое совместное использование систем с разделением времени.

time_slice

Время расчета приоритета процесса

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

Источник