Может ли SCHED_FIFO быть вытеснен SCHED_DEADLINE?
В меню : Системные настройки: Окно входа в систему вы можете выбрать свою тему. у вас есть 'Mint-X', вы можете отредактировать настройки этой темы:
sudo gedit /usr/share/mdm/html-themes/Mint-X/slideshow.conf
и отредактировать список изображений, случайно используемых на экране входа в систему ура
Справочная страница верна. Подтверждение этому найти несложно.
/ * * задачи SCHED_DEADLINE имеют отрицательный приоритет, что отражает * тот факт, что любая из них имеет более высокий приоритет, чем RT и * задачи NORMAL / BATCH. * / #define MAX_DL_PRIO 0
Это был подход, выбранный разработчиком планировщика Linux. Я процитировал объяснение LWN ниже, хотя вы должны стремиться прочитать всю любую статью LWN, которая имеет отношение к вашим интересам. Поскольку они имеют ограниченную длину, я не могу гарантировать, что они разрешат каждую конкретную путаницу, которая может у вас возникнуть. https: // lwn.net / Articles / 356576 /
Питер Зийлстра, однако, считает, что планирование крайних сроков должно выполняться с наивысшим приоритетом; в противном случае он не может гарантировать соблюдение сроков.
Я немного сбит с толку, так как думал, что rtprio 99 будет наивысшим приоритетом в системе (сторожевые таймеры, миграция, posixcputimer ...).
LWN ссылается на первоначальный обзор Питера , в котором упоминается это.
Единственные две задачи, которые должны иметь абсолютный наивысший приоритет, - это kstopmachine и migrate, поэтому их нужно будет поднять выше EDF, остальное не важно: -)
Я не знаю точно, что такое миграция в этом контексте, но статья LWN действительно называет SMP в реальном времени проблемой.
Stopmachine находится в списке, который говорит: «Так что не делайте этого для RT!», По этой причине. Петр делает это явным позже .
Сторожевые псы, несомненно, работают в большем масштабе времени, чем процессы в реальном времени, и планирование крайних сроков оставляет время для их выполнения позже (см. Ниже).
По иронии судьбы, я изо всех сил пытаюсь найти информацию о поведении таймеров в ядре реального времени. Есть RT wiki , в которой это упоминается для приоритетов, но не для крайних сроков ... обратите внимание, что страница последний раз редактировалась в 2008 году и указывает тестовую машину с процессором PIII 400 Mhz. Также интересно, что в первоначальном обзоре Питер не упомянул таймеры. Похоже, что процессам RT было рекомендовано использовать clock_nanosleep (), если это возможно. (Ясно, что это будет мало или совсем не полезно для часов CPUTIME, о которых вы, возможно, имеете в виду).
Планировщик крайних сроков может гарантировать соблюдение крайних сроков при условии, что процессы не превышают установленное для них время выполнения наихудшего случая. Планировщик приоритетов не имеет этой функции.
Сопровождающие предпочли эту гарантию, а не ставили ее в зависимость от наличия процесса SCHED_FIFO. Планирование сроков без гарантии было бы совсем другим зверьком ... независимо от того, будет ли это иметь некоторую полезность; Я действительно не знаю.
Запланированные процессы крайнего срока имеют максимальную пропускную способность, которая обеспечивается планировщиком Linux. В принципе, должна быть возможность посмотреть на общую пропускную способность процессов, запланированных в крайний срок, а также на самый большой период выполнения и определить наихудший эффект для любых запланированных процессов с приоритетом. Обратное не было бы правдой, потому что нет принудительного применения WCET для класса планирования POSIX SCHED_FIFO.
Система крайних сроков устраняет статические приоритеты. Вместо этого каждая запущенная задача предоставляет набор из трех параметров планирования:
- Крайний срок - когда работа должна быть завершена.
- Срок выполнения - как часто работа должна выполняться.
- Наихудшее время выполнения (WCET) - максимальное количество процессорного времени, которое потребуется для выполнения работы.
Требование процесса к «полосе пропускания» - какой процент ЦП ему требуется - легко вычислить, поэтому планировщик с самого начала знает, превышена ли подписка в системе или нет. Планировщик может (и должен) отказаться принимать задачи, которые потребуют большей пропускной способности, чем имеет система.Отказавшись от лишней работы, планировщик всегда сможет предоставить необходимое процессорное время для каждого процесса в течение указанного крайнего срока. Такое обещание радует разработчиков в реальном времени.